Re: [openstack-dev] [fuel] Component Leads Elections
ns >> for us! >> >> -- >> Dmitry Borodaenko >> >> >> On Thu, Mar 24, 2016 at 12:55:57PM -0700, Serg Melikyan wrote: >> > Hi folks, >> > >> > I'd like to announce that we're running the Component Leads elections. >> > Detailed information is available on wiki [0]. >> > >> > Component Lead: defines architecture of a particular module or >> > component in Fuel, resolves technical disputes in their area of >> > responsibility. All design specs that impact a component must be >> > approved by the corresponding component lead [1]. >> > >> > Fuel has three large sub-teams, with roughly comparable codebases, >> > that need dedicated component leads: >> > >> > * fuel-library >> > * fuel-web >> > * fuel-ui >> > >> > Nominees propose their candidacy by sending an email to the >> > openstack-dev@lists.openstack.org mailing-list, with the subject: >> > "[fuel] lead candidacy" >> > (for example, "[fuel] fuel-library lead candidacy"). >> > >> > Timeline: >> > * March 25 - March 31: Open candidacy for Component leads positions >> > * April 1 - April 7: Component leads elections >> > >> > References >> > [0] https://wiki.openstack.org/wiki/Fuel/Elections_Spring_2016 >> > [1] >> https://specs.openstack.org/openstack/fuel-specs/policy/team-structure.html >> > >> > -- >> > Serg Melikyan, Development Manager at Mirantis, Inc. >> > http://mirantis.com | smelik...@mirantis.com >> > >> > >> __ >> > OpenStack Development 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 >> >> __ >> OpenStack Development 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 >> > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][Nailgun] Random failures in unit tests
I finally got it passing all the tests, including performance: https://review.openstack.org/#/c/294976/. I'd appreciate if you guys can review/land it sooner than later: patch touches many tests, and it would be beneficial for everyone to be based on updated code. Thanks, On Mon, Mar 21, 2016 at 12:22 AM Mike Scherbakov <mscherba...@mirantis.com> wrote: > FakeUI, which is based on fake threads, is obviously needed for > development purposes. > Ideally we need to refactor our integration tests, so that we don't run > whole pipeline in every test. To start, I suggest that we switch from > threads to synchronous runs of test cases (while keeping threads for > fakeUI). > Please take a look & comment in this draft: > https://review.openstack.org/#/c/294976/ > > Thanks, > > On Wed, Mar 16, 2016 at 7:30 AM Igor Kalnitsky <ikalnit...@mirantis.com> > wrote: > >> Hey Vitaly, >> >> Thanks for your feedback, it's an important notice. However, I think >> you didn't get the problem quite well so let me explain it again. >> >> You see, Nailgun unit tests are failing due to races or deadlocks >> happened by two transactions: test transaction and fake thread >> transaction, and we must face it and fix it. This problem has nothing >> to do with the problem you're encountering in UI tests. Besides, >> removing them from test doesn't mean removing them from Nailgun code >> base. >> >> So your problem must be addressed, but it's kinda another story. >> >> Thanks, >> Igor >> >> On Wed, Mar 16, 2016 at 4:21 PM, Vitaly Kramskikh >> <vkramsk...@mirantis.com> wrote: >> > Igor, >> > >> > We have UI and CLI integration tests which use fake mode of Nailgun, >> and we >> > can't avoid using fake threads for them. So I think we need to think >> how to >> > fix fake threads instead. There is a critical bug which is the main >> reason >> > of randomly failing UI tests. To fix it, we need to fix fake threads >> > behaviour. >> > >> > 2016-03-16 17:06 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>: >> >> >> >> Hey Fuelers, >> >> >> >> As you might know recently we encounter a lot of random test failures >> >> on CI, and they are still there (likely with a bit less probability). >> >> A nature of that random failures is actually not a random, they are >> >> happened because of so called fake threads. >> >> >> >> Fake threads, actually, ain't fake at all. They are native OS threads >> >> that are designed to emulate Astute behaviour (i.e. catch RPC call and >> >> respond with appropriate message). Since they are native threads and >> >> we use SQLAlchemy's scoped_session, fake threads are using a separate >> >> database session, hence - transaction. That leads to the following >> >> issues: >> >> >> >> * Races. We don't know when threads are switched, therefore, we don't >> >> know what's committed and what's not. Some Nailgun tests sends >> >> something via RPC (catched by fake threads) and immediately checks >> >> something. The issue is, we can't guarantee fake threads is already >> >> committed produced result. That could be avoided by waiting for >> >> 'ready' status of created nailgun task, however, it's better to simply >> >> do not use fake threads in that case and simply call appropriate >> >> Nailgun receiver's method directly in the test. >> >> >> >> * Deadlocks. It's incredibly hard to ensure the same order of database >> >> locks in test + business code on one hand and fake thread code on >> >> other hand. That's why we can (and we do) encounter deadlocks on CI, >> >> when test case waits for lock acquired by fake thread, and fake thread >> >> waits for lock acquired by test case. >> >> >> >> Fake threads are became a bottleneck of landing patches to master in >> >> time, and we can't ignore it anymore. We have ~190 tests that use fake >> >> threads, and fixing them all at once is a boring routine. So I kindly >> >> ask Nailgun contrubitors to fix them as soon as we face them. Let's >> >> file a bug on each file in CI, and quicly prepare a separate patch >> >> that removes fake thread from failed test. >> >> >> >> Thanks in advance, >> >> Igor >> >> >> >> >> __ >> >> OpenS
Re: [openstack-dev] [Fuel][Nailgun] Random failures in unit tests
FakeUI, which is based on fake threads, is obviously needed for development purposes. Ideally we need to refactor our integration tests, so that we don't run whole pipeline in every test. To start, I suggest that we switch from threads to synchronous runs of test cases (while keeping threads for fakeUI). Please take a look & comment in this draft: https://review.openstack.org/#/c/294976/ Thanks, On Wed, Mar 16, 2016 at 7:30 AM Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Hey Vitaly, > > Thanks for your feedback, it's an important notice. However, I think > you didn't get the problem quite well so let me explain it again. > > You see, Nailgun unit tests are failing due to races or deadlocks > happened by two transactions: test transaction and fake thread > transaction, and we must face it and fix it. This problem has nothing > to do with the problem you're encountering in UI tests. Besides, > removing them from test doesn't mean removing them from Nailgun code > base. > > So your problem must be addressed, but it's kinda another story. > > Thanks, > Igor > > On Wed, Mar 16, 2016 at 4:21 PM, Vitaly Kramskikh > <vkramsk...@mirantis.com> wrote: > > Igor, > > > > We have UI and CLI integration tests which use fake mode of Nailgun, and > we > > can't avoid using fake threads for them. So I think we need to think how > to > > fix fake threads instead. There is a critical bug which is the main > reason > > of randomly failing UI tests. To fix it, we need to fix fake threads > > behaviour. > > > > 2016-03-16 17:06 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>: > >> > >> Hey Fuelers, > >> > >> As you might know recently we encounter a lot of random test failures > >> on CI, and they are still there (likely with a bit less probability). > >> A nature of that random failures is actually not a random, they are > >> happened because of so called fake threads. > >> > >> Fake threads, actually, ain't fake at all. They are native OS threads > >> that are designed to emulate Astute behaviour (i.e. catch RPC call and > >> respond with appropriate message). Since they are native threads and > >> we use SQLAlchemy's scoped_session, fake threads are using a separate > >> database session, hence - transaction. That leads to the following > >> issues: > >> > >> * Races. We don't know when threads are switched, therefore, we don't > >> know what's committed and what's not. Some Nailgun tests sends > >> something via RPC (catched by fake threads) and immediately checks > >> something. The issue is, we can't guarantee fake threads is already > >> committed produced result. That could be avoided by waiting for > >> 'ready' status of created nailgun task, however, it's better to simply > >> do not use fake threads in that case and simply call appropriate > >> Nailgun receiver's method directly in the test. > >> > >> * Deadlocks. It's incredibly hard to ensure the same order of database > >> locks in test + business code on one hand and fake thread code on > >> other hand. That's why we can (and we do) encounter deadlocks on CI, > >> when test case waits for lock acquired by fake thread, and fake thread > >> waits for lock acquired by test case. > >> > >> Fake threads are became a bottleneck of landing patches to master in > >> time, and we can't ignore it anymore. We have ~190 tests that use fake > >> threads, and fixing them all at once is a boring routine. So I kindly > >> ask Nailgun contrubitors to fix them as soon as we face them. Let's > >> file a bug on each file in CI, and quicly prepare a separate patch > >> that removes fake thread from failed test. > >> > >> Thanks in advance, > >> Igor > >> > >> > __ > >> OpenStack Development 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 > > > > > > > > > > -- > > Vitaly Kramskikh, > > Fuel UI Tech Lead, > > Mirantis, Inc. > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
We can sort out details later. In a worst case, the warning will be there in Newton too, and feature will go away only in O* release. So let's proceed with the bug.. On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh <vkramsk...@mirantis.com> wrote: > We can add the warning, but I think before we do this we should have clear > migration plan. According to this thread, some parts are still not clear. > > 2016-03-11 22:00 GMT+03:00 Mike Scherbakov <mscherba...@mirantis.com>: > >> Deprecation warning for Fuel Mitaka: >> https://bugs.launchpad.net/fuel/+bug/1556244. >> >> >> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko <m...@romcheg.me> >> wrote: >> >>> Since there are a lot of supporters for this idea, what do you folks >>> think about creating a BP spec where we can describe what we should do in >>> order to remove logs from UI and Nailgun? I also propose to file a bug >>> about adding a deprecation warning to Mitaka release of Fuel. >>> >>> >>> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya <bdobre...@mirantis.com> >>> написав(ла): >>> >>> >>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote: >>> >>> +1 to remove logs from Fuel UI in Fuel Newton. >>> In Fuel Mitaka we'd need to put a deprecation warning somewhere. >>> >>> >>> I agree, there is not much sense having non flexible (no content >>> filters) logs view in UI. LMA plugins shall cover this area as well. >>> >>> >>> >>> On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppe...@mirantis.com >>> <mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> wrote: >>> >>> >>>On 11 March 2016 at 12:51:40, Igor Kalnitsky >>>(ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com >>> <ikalnit...@mirantis.com>>) wrote: >>> >>>Patrick, >>> >>>Sorry, but I meant another question. I thought that LMA plugin should >>> >>>be installed in some environment before we can start use it. Is >>>this a >>>case? If so, it means we can't use for master node until some >>>environment is deployed. >>> >>> >>>Right. This is the chicken and egg problem I mentioned earlier... >>> >>>But this is not a “problem” specific to Fuel. My take on this is is >>>that ops management tooling (logging, monitoring) should be >>>installed off-band before any OpenStack deployment. In fact, in >>>real-world usage, we frequently get asks to have the monitoring and >>>logging services of StackLight installed permanently for >>>multi-enviroments. And so, one approach would be to make Stacklight >>>backend services the first bits of software installed by Fuel (if >>>not already there), then reconfigure Fuel to hook into those >>>services and only then, enter into the regular OpenStack >>>provisioning mode. >>> >>> >>> >>>On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit >>><ppe...@mirantis.com <mailto:ppe...@mirantis.com >>> <ppe...@mirantis.com>>> wrote: >>> >>> >>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com < >>> mailto:ikalnit...@mirantis.com <ikalnit...@mirantis.com>>) >>> wrote: >>> >>> Hey Roman, >>> >>> Thank you for bringing this up. +1 from my side, especially taking >>> into account the patch where we tried to solve logrotated logs problem >>> [1]. It's complex and unsupportable, as well as already existed >>> logview code in Nailgun. >>> >>> Patrick, Simon, >>> >>> Does LMA plugin support logs from master node? Or it's designed to >>> watch environment's logs? >>> >>> No it’s not designed specifically for environment logs. Can be adapted to >>> >>> any log format. >>> >>> Would just need to write a parser like you would with logstach when logs >>> are >>> not standard. >>> >>> Patrick >>> >>> >>> >>> Thanks, >>> Igor >>> >>> >>> [1]: https://review.openstack.org/#/c/243240/ >>> >>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com < >>> mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> wrote: >>> >>> Fuelers, >>> >>> As Simon said, we already have a
Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
Deprecation warning for Fuel Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244. On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko <m...@romcheg.me> wrote: > Since there are a lot of supporters for this idea, what do you folks think > about creating a BP spec where we can describe what we should do in order > to remove logs from UI and Nailgun? I also propose to file a bug about > adding a deprecation warning to Mitaka release of Fuel. > > > 11 бер. 2016 р. о 16:55 Bogdan Dobrelya <bdobre...@mirantis.com> > написав(ла): > > > On 03/11/2016 04:46 PM, Mike Scherbakov wrote: > > +1 to remove logs from Fuel UI in Fuel Newton. > In Fuel Mitaka we'd need to put a deprecation warning somewhere. > > > I agree, there is not much sense having non flexible (no content > filters) logs view in UI. LMA plugins shall cover this area as well. > > > > On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppe...@mirantis.com > <mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> wrote: > > >On 11 March 2016 at 12:51:40, Igor Kalnitsky >(ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com > <ikalnit...@mirantis.com>>) wrote: > >Patrick, > >Sorry, but I meant another question. I thought that LMA plugin should >be installed in some environment before we can start use it. Is >this a >case? If so, it means we can't use for master node until some >environment is deployed. > > >Right. This is the chicken and egg problem I mentioned earlier... > >But this is not a “problem” specific to Fuel. My take on this is is >that ops management tooling (logging, monitoring) should be >installed off-band before any OpenStack deployment. In fact, in >real-world usage, we frequently get asks to have the monitoring and >logging services of StackLight installed permanently for >multi-enviroments. And so, one approach would be to make Stacklight >backend services the first bits of software installed by Fuel (if >not already there), then reconfigure Fuel to hook into those >services and only then, enter into the regular OpenStack >provisioning mode. > > > >On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit ><ppe...@mirantis.com <mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> > wrote: > > > On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com < > mailto:ikalnit...@mirantis.com <ikalnit...@mirantis.com>>) > wrote: > > Hey Roman, > > Thank you for bringing this up. +1 from my side, especially taking > into account the patch where we tried to solve logrotated logs problem > [1]. It's complex and unsupportable, as well as already existed > logview code in Nailgun. > > Patrick, Simon, > > Does LMA plugin support logs from master node? Or it's designed to > watch environment's logs? > > No it’s not designed specifically for environment logs. Can be adapted to > any log format. > > Would just need to write a parser like you would with logstach when logs > are > not standard. > > Patrick > > > > Thanks, > Igor > > > [1]: https://review.openstack.org/#/c/243240/ > > On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppe...@mirantis.com < > mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> wrote: > > Fuelers, > > As Simon said, we already have a log centralisation solution for MOS > delivered as a Fuel plugins known as StackLight / LMA toolset. And so > objectively, there is no need to have log management in Nailgun anymore. > To > go one step further we suggested several times to have a StackLight agent > installed on the Fuel master node to also collect and centralise those > logs. > There is a little bit of a chicken and egg problem to resolve but I think > it > is worth a try to have that nailed down in the roadmap for Fuel 10. > Cheers > - Patrick > > > On 11 March 2016 at 10:07:28, Simon Pasquier (spasqu...@mirantis.com < > mailto:spasqu...@mirantis.com <spasqu...@mirantis.com>>) > wrote: > > Hello Roman, > > On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me < > mailto:m...@romcheg.me <m...@romcheg.me>>> > wrote: > > > Fuelers, > > I remember we’ve discussing this topic in our couloirs before but I’d > like > to bring that discussion to a more official format. > > Let me state a few reasons to do this: > > - Log management code in Nailgun is overcomplicated > - Working with logs on big scale deployments is barely possible given the > current representation > - Due to overcomplexity and ineffectiveness of the code we alw
Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and Nailgun
;> the box > >> > >> > >> This is what the LMA/StackLight plugins [1][2] are meant for. No need to > > >> develop anything new. > >> > >> And I'm +1 with the removal of log management from Fuel. As you said, it > > >> can't scale... > >> > >> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/ > >> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/ > >> > >> > >>> > >>> > >>> > >>> References > >>> 1. https://bugs.launchpad.net/fuel/+bug/1553170 > >>> 2. https://www.elastic.co/products/logstash > >>> > >>> > >>> - romcheg > >>> > >>> > >>> > __ > > >>> OpenStack Development 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 > >>> > >> > >> > __ > > >> OpenStack Development 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 > >> > >> > >> > __ > > >> OpenStack Development 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 > >> > > > > > __ > > > OpenStack Development 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 > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Thank you for comments folks. Clarifications, with the feedback incorporated: 1) We can install plugin developed against 8 to Fuel Mitaka (9). But it won't appear in the UI as available plugin. This is what I want to fix, and have just a warning that this plugin may not work. 2) To clarify, I'm talking about using plugin developed against 8.0-liberty in 9.0-mitaka, e.g. in newer Fuel with newer OpenStack release deployed. I understand that we've changed names of tasks, and now it's just impossible to have any meaningful plugin developed against 8 which would work in Mitaka without other task names, etc. But - do we expect renames over again and again? Any other changes? I hope the answer is no, that we want to stabilize an interface. I understand, that new OpenStack release may require changes in tasks, new tasks would appear, new dependencies. However, I assume that vast majority of components don't change that often. So, do we have any suggestions how we can keep tasks and whatever else from changes? Can we introduce backward compatibility here? I'm trying to understand how hard it will be to make. As otherwise, every plugin developer will have to learn new tasks every new release, and re-do the work. 3) Multi-release support is kinda covered in (2) here. If plugin's code needs little tweaks in order to support new release of Fuel, I'd suggest to figure out how we can use inheritance and keep code for multiple Fuel releases in one plugin repo. In current reality, when it means to fork almost everything, I'm in a support of having a plugin branch per Fuel release. Thanks for links to the corresponding thread and plugins v5 spec, I'll take a careful look. > So I don't quite understand how new"validated_against" parameter will differ from existing "releases" list. Alex, I meant to have different use of what we have now. Instead of blocking a user from using a plugin in "unsupported" Fuel version, allow it - but warn. Thanks, On Thu, Mar 10, 2016 at 4:50 AM Aleksandr Didenko <adide...@mirantis.com> wrote: > > Good idea. That should be done despite on any decision we will take. > > Currently you have to specify which releases your plugin supports [0]. So > I can take my plugin developed for 8.0 and install it on Fuel-9.0 (I > actually did it and it worked just fine). But I won't be able to enable > this plugin for "mitaka-9.0" release because plugin was not developed and > tested for it, so it does not have "miraka-9.0" in "releases" list [0]. So > I don't quite understand how new "validated_against" parameter will > differ from existing "releases" list. > > Regards, > Alex > > [0] > https://github.com/openstack/fuel-plugin-external-lb/blob/68fc91a2d3360f19605180d7c3d8683227c8d5b1/metadata.yaml#L11-L21 > > > On Thu, Mar 10, 2016 at 10:22 AM, Bogdan Dobrelya <bdobre...@mirantis.com> > wrote: > >> On 10.03.2016 08:30, Mike Scherbakov wrote: >> > Hi folks, >> > in order to make a decision whether we need to support example plugins, >> > and if actually need them [1], I'd suggest to discuss more common things >> > about plugins. >> > >> > My thoughts: >> > 1) This is not good, that our plugins created for Fuel 8 won't even >> > install on Fuel 9. By default, we should assume that plugin will work at >> > newer version of Fuel. However, for proper user experience, I suggest to >> > create meta-field "validated_against", where plugin dev would provide >> > versions of Fuel this plugin has been tested with. Let's say, it was >> > tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest >> > to show a warning saying about risks and the fact that the plugin has >> > not been tested against 9. We should not restrict intsallation against >> > 9, though. >> >> Good idea. That should be done despite on any decision we will take. >> >> > >> > 2) We need to keep backward compatibility of pluggable interface for a >> > few releases. So that plugin developer can use pluggable interface of >> > version x, which was supported in Fuel 6.1. If we still support it, it >> > would mean (see next point) compatibility of this plugin with 6.1, 7.0, >> > 8.0, 9.0. If we want to deprecate pluggable interface version, we should >> > announce it, and basically follow standard process of deprecation. >> > >> > 3) Plugin's ability to work against multiple releases of Fuel >> > (multi-release support). If if..else clauses to support multiple >> > releases are fairly minimal, let's say take less that 10% of LOC, I'd >> > suggest to have this supported. Just because it will be easier for &g
Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?
Regarding #2 > we already generate from templates required information for a plugin developer to start development and it is great. So, back to what I said: > However, we can have fpb generating template plugin, with commented code in there. If you uncomment, you a get a comprehensive example of a working plugin. To ensure that uncommented code would actually work, we must have a test for it (which would uncomment - run - ensure everything deploys). We already have great template plugins generated by fpb. Question is, how do we ensure that this generated template actually works. > # 3 adding real deployment test for fuel-plugins will not help here, since change in openstack.yaml caused this problem. True. That's why I started new thread, where I suggest that we must allow to install older plugins into new releases of Fuel, with the warning only. > Well, what about tomorrow? On SCF we create stable branches and master is open for next release. You probably will want to run those tests against Fuel 10, and FPB's master won't have that "10" release in examples metadata. True Igor, please see my same answer to Evgeny above - we need to change pluggable framework to allow installation of older plugins to newer releases of Fuel. Before we do that, I suggest to extend supported releases list right away to Newton. No need to wait for new bug from QA. On Thu, Mar 10, 2016 at 5:44 AM Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Well, what about tomorrow? On SCF we create stable branches and master > is open for next release. You probably will want to run those tests > against Fuel 10, and FPB's master won't have that "10" release in > examples metadata. Because it's something that we usually don't want > to release, and FPB lifecycle is untied from Fuel's. > > The only way to avoid that problem is to teach tests to prepare > plugins themselves. They are like test fixtures, it's not very good > that your rely on something that you don't maintain. > > On Thu, Mar 10, 2016 at 11:01 AM, Evgeniy L <e...@mirantis.com> wrote: > > Mike, > > > > # 2 don't agree, we already generate from templates required information > for > > a plugin developer to start development, purpose of plugin examples is > > different, it's used as integration tests for plugins, also QA team uses > > them as Functional tests, they overloaded with tasks and designed to have > > good coverage, so it will only confuse plugin developer. > > # 3 adding real deployment test for fuel-plugins will not help here, > since > > change in openstack.yaml caused this problem. > > > > Thanks, > > > > On Thu, Mar 10, 2016 at 10:55 AM, Matthew Mosesohn < > mmoses...@mirantis.com> > > wrote: > >> > >> Mike, > >> > >> #1 - If you truly agree with that, you should weigh in here: > >> https://review.openstack.org/#/c/287286/ > >> #2 - Requires a blueprint and new docs, but okay. > >> #3 - Yes! We have very poor CI for fuel plugin builder. All it does is > >> ensure it makes a plugin, not that it can be installed and deployed. > >> > >> On Thu, Mar 10, 2016 at 10:44 AM, Mike Scherbakov > >> <mscherba...@mirantis.com> wrote: > >> > Folks, > >> > here is what I think: > >> > 1) I suggest to fix what is broken now. So that people who come across > >> > examples would not have to deal with issues. We may debate for other > few > >> > days (hopefully not more), and all plugin devs will be suffering > during > >> > this > >> > time. Also, according to Matt, > >> > > >> >> I should add that this is the only automated daily test that will > >> >> verify > >> > that our plugin framework actually works. > >> > simply means that we must fix it in order to catch any possible > >> > regressions > >> > we may introduce later (if not already). > >> > > >> > 2) I like idea Ilya K. has proposed. To rephrase it (to put extra > accent > >> > into it and get feedback), we may not need to have example plugins. > >> > However, > >> > we can have fpb generating template plugin, with commented code in > >> > there. If > >> > you uncomment, you a get a comprehensive example of a working plugin. > >> > To ensure that uncommented code would actually work, we must have a > test > >> > for > >> > it (which would uncomment - run - ensure everything deploys). > >> > > >> > 3) Ideally, we need to catch issues at pre-commit stage. So I'd > suggest > >> > to > >> >
Re: [openstack-dev] [fuel][plugins] Should we maintain example plugins?
t;> >>> >>>>> >> >>> I would like to bring your attention a dilemma we have here. It >>>>> seems >>>>> >> >>> that there is a dispute as to whether we should maintain the >>>>> releases >>>>> >> >>> list for example plugins[0]. In this case, this is for adding >>>>> version >>>>> >> >>> 9.0 to the list. >>>>> >> >>> >>>>> >> >>> Right now, we run a swarm test that tries to install the example >>>>> >> >>> plugin and do a deployment, but it's failing only for this >>>>> reason. I >>>>> >> >>> should add that this is the only automated daily test that will >>>>> verify >>>>> >> >>> that our plugin framework actually works. During the Mitaka >>>>> >> >>> development cycle, we already had an extended period where >>>>> plugins >>>>> >> >>> were broken[1]. Removing this test (or leaving it permanently >>>>> red, >>>>> >> >>> which is effectively the same), would raise the risk to any >>>>> member of >>>>> >> >>> the Fuel community who depends on plugins actually working. >>>>> >> >>> >>>>> >> >>> The other impact of abandoning maintenance of example plugins >>>>> is that >>>>> >> >>> it means that a given interested Fuel Plugin developer would >>>>> not be >>>>> >> >>> able to easily get started with plugin development. It might >>>>> not be >>>>> >> >>> inherently obvious to add the current Fuel release to the >>>>> >> >>> metadata.yaml file and it would likely discourage such a user. >>>>> In this >>>>> >> >>> case, I would propose that we remove example plugins from >>>>> fuel-plugins >>>>> >> >>> GIT repo if they are not maintained. Non-functioning code is >>>>> worse >>>>> >> >>> than deleted code in my opinion. >>>>> >> >>> >>>>> >> >>> Please share your opinions and let's decide which way to go >>>>> with this >>>>> >> >>> bug[2] >>>>> >> >>> >>>>> >> >>> [0] >>>>> https://github.com/openstack/fuel-plugins/tree/master/examples >>>>> >> >>> [1] https://bugs.launchpad.net/fuel/+bug/1544505 >>>>> >> >>> [2] https://launchpad.net/bugs/1548340 >>>>> >> >>> >>>>> >> >>> Best Regards, >>>>> >> >>> Matthew Mosesohn >>>>> >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> __ >>>>> >> >>> OpenStack Development 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 >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> __ >>>>> >> >> OpenStack Development 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 >>>>> >> >> >>>>> >> > >>>>> >> > >>>>> >> > >>>>> __ >>>>> >> > OpenStack Development 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 >>>>> >> >>>>> >> >>>>> __ >>>>> >> OpenStack Development 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 >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > -- >>>>> > with best regards, >>>>> > Stan. >>>>> > >>>>> > >>>>> __ >>>>> > OpenStack Development 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 >>>>> > >>>>> >>>>> >>>>> __ >>>>> OpenStack Development 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 >>>>> >>>> >>>> >>>> >>>> __ >>>> OpenStack Development 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 >>>> >>>> >>> >>> >>> __ >>> OpenStack Development 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 >>> >>> >> >> __ >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Compatibility of fuel plugins and fuel versions
Hi folks, in order to make a decision whether we need to support example plugins, and if actually need them [1], I'd suggest to discuss more common things about plugins. My thoughts: 1) This is not good, that our plugins created for Fuel 8 won't even install on Fuel 9. By default, we should assume that plugin will work at newer version of Fuel. However, for proper user experience, I suggest to create meta-field "validated_against", where plugin dev would provide versions of Fuel this plugin has been tested with. Let's say, it was tested against 7.0, 8.0. If user installs plugin in Fuel 9, I'd suggest to show a warning saying about risks and the fact that the plugin has not been tested against 9. We should not restrict intsallation against 9, though. 2) We need to keep backward compatibility of pluggable interface for a few releases. So that plugin developer can use pluggable interface of version x, which was supported in Fuel 6.1. If we still support it, it would mean (see next point) compatibility of this plugin with 6.1, 7.0, 8.0, 9.0. If we want to deprecate pluggable interface version, we should announce it, and basically follow standard process of deprecation. 3) Plugin's ability to work against multiple releases of Fuel (multi-release support). If if..else clauses to support multiple releases are fairly minimal, let's say take less that 10% of LOC, I'd suggest to have this supported. Just because it will be easier for plugin devs to support their plugin code (no code duplication, single repo for multiple releases). Thoughts? [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088211.html -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2
It is not just about BVT. I'd suggest to monitor situation overall, including failures of system tests [1]. If we see regressions there, or some test cases will start flapping (what is even worse), then we'd have to revert back to CentOS 7.1. [1] https://github.com/openstack/fuel-qa On Wed, Mar 2, 2016 at 10:16 AM Dmitry Borodaenko <dborodae...@mirantis.com> wrote: > I agree with Mike's concerns, and propose to make these limitations (4 > weeks before FF for OS upgrades, 2 weeks for upgrades of key > dependencies -- RabbitMQ, MCollective, Puppet, MySQL, PostgreSQL, > anything else?) official for 10.0/Newton. > > For 9.0/Mitaka, it is too late to impose them, so we just have to be > very careful and conservative with this upgrade. First of all, we need > to have a green BVT before and after switching to the CentOS 7.2 repo > snapshot, so while I approved the spec, we can't move forward with this > until BVT is green again, and right now it's red: > > https://ci.fuel-infra.org/job/9.0.fuel_community.ubuntu.bvt_2/ > > If we get it back to green but it becomes red after the upgrade, you > must switch back to CentOS 7.1 *immediately*. If you are able to stick > to this plan, there is still time to complete the transition today > without requiring an FFE. > > -- > Dmitry Borodaenko > > > On Wed, Mar 02, 2016 at 05:53:53PM +, Mike Scherbakov wrote: > > Formally, we can merge it today. Historically, every update of OS caused > us > > instability for some time: from days to a couple of month. > > Taking this into account and number of other exceptions requested, > overall > > stability of code, my opinion would be to postpone this to 10.0. > > > > Also, I'd suggest to change the process, and have freeze date for all OS > > updates no later than a month before official FF date. This will give us > > time to stabilize, and ensure that base on which all new code is being > > developed is stable when approaching FF. > > > > I'd also propose to have freeze for major upgrades of 3rd party packages > no > > later than 2 weeks before FF, which Fuel depends heavily upon. For > > instance, such will include RabbitMQ, MCollective, Puppet. > > > > On Wed, Mar 2, 2016 at 7:34 AM Igor Marnat <imar...@mirantis.com> wrote: > > > > > Igor, > > > couple of points from my side. > > > > > > CentOS 7.2 will be getting updates for several more months, and we have > > > snapshots and all the mechanics in place to switch to the next version > when > > > needed. > > > > > > Speaking of getting this update into 9.0, we actually don't need FFE, > we > > > can merge remaining staff today. It has enough reviews, so if you add > your > > > +1 today, we don't need FFE. > > > > > > https://review.openstack.org/#/c/280338/ > > > https://review.fuel-infra.org/#/c/17400/ > > > > > > > > > > > > Regards, > > > Igor Marnat > > > > > > On Wed, Mar 2, 2016 at 6:23 PM, Dmitry Teselkin < > dtesel...@mirantis.com> > > > wrote: > > > > > >> Igor, > > >> > > >> Your statement about updates for 7.2 isn't correct - it will receive > > >> updates, because it's the latest release ATM. There is *no* pinning > inside > > >> ISO, and the only place where it was 8.0 were docker containers just > > >> because we had to workaround some issues. But there are no docker > > >> containers in 9.0, so that's not the case. > > >> The proposed solution to switch to CentOS-7.2 in fact is based on > > >> selecting the right snapshot with packages. There is no pinning in > ISO (it > > >> was in earlier versions of the spec but was removed). > > >> > > >> On Wed, Mar 2, 2016 at 6:11 PM, Igor Kalnitsky < > ikalnit...@mirantis.com> > > >> wrote: > > >> > > >>> Dmitry, Igor, > > >>> > > >>> > Very important thing is that CentOS 7.1 which master node is based > now > > >>> > don't get updates any longer. > > >>> > > >>> If you are using "fixed" release you must be ready that you won't get > > >>> any updates. So with CentOS 7.2 the problem still the same. > > >>> > > >>> However, let's wait for Fuel PTL decision. I only shared my POV: > > >>> that's not a critical feature, and taking into account the risks of > > >>> regression - I'd prefer to do not accept it in 9.0. > > >>> > > >>> Regards
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request - switching to CentOS-7.2
tOS-72 is not that >>> dangerous >>> >> as it seems. >>> >> >>> >> On Wed, Mar 2, 2016 at 1:54 PM, Igor Kalnitsky < >>> ikalnit...@mirantis.com> >>> >> wrote: >>> >>> >>> >>> Hey Dmitry, >>> >>> >>> >>> No offence, but I rather against that exception. We have too many >>> >>> things to do in Mitaka, and moving to CentOS 7.2 means >>> >>> >>> >>> * extra effort from core team >>> >>> * extra effort from qa team >>> >>> >>> >>> Moreover, it might block development by introducing unpredictable >>> >>> regressions. Remember 8.0? So I think 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 < >>> dtesel...@mirantis.com> >>> >>> wrote: >>> >>> > I'd like to ask for a feature freeze exception for switching to >>> >>> > CentOS-7.2 >>> >>> > feature [0]. >>> >>> > >>> >>> > CentOS-7.2 ISO's have been tested periodically since the beginning >>> of >>> >>> > the >>> >>> > year, and all major issues were addressed / fixed at the moment. >>> During >>> >>> > the >>> >>> > last weekend I've made 70 BVT runs to verify that the solution >>> [2] for >>> >>> > the >>> >>> > last issue - e1000 transmit unit hangs works. And it works, 0 >>> tests of >>> >>> > 35 >>> >>> > failed [3]. >>> >>> > >>> >>> > Benefits of switching to CentOS-7.2 are quite obvious - we will >>> return >>> >>> > to >>> >>> > latest supported CentOS release, will fix a lot of bugs / security >>> >>> > issues >>> >>> > [4] and will make further updates easier. >>> >>> > >>> >>> > Risk of regression still exists, but it's quite low, 35 successful >>> BVTs >>> >>> > can't be wrong. >>> >>> > >>> >>> > To finish that feature the following should be done: >>> >>> > * review and merge e1000 workaround [2] >>> >>> > * review and merge spec [0] >>> >>> > * review and merge request that switches build CI to CentOS-7.2 [5] >>> >>> > >>> >>> > I expect the last day it could be done is March, 4. >>> >>> > >>> >>> > [0] https://review.openstack.org/#/c/280338/ >>> >>> > [1] https://bugs.launchpad.net/fuel/+bug/1526544 >>> >>> > [2] https://review.openstack.org/#/c/285306/ >>> >>> > [3] >>> https://etherpad.openstack.org/p/r.1c4cfee8185326d6922d6c9321404350 >>> >>> > [4] >>> https://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) >>> >>> > Unsubscribe: >>> >>> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> > >>> >>> >>> >>> >>> >>> >>> __ >>> >>> OpenStack Development 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 >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Thanks, >>> >> Dmitry Teselkin >>> >> Mirantis >>> >> http://www.mirantis.com >>> >> >>> >> >>> __ >>> >> OpenStack Development 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 >>> >> >>> > >>> > >>> > >>> __ >>> > OpenStack Development 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 >>> > >>> >>> >>> __ >>> OpenStack Development 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 >>> >> >> >> >> -- >> Thanks, >> Dmitry Teselkin >> Mirantis >> http://www.mirantis.com >> >> __ >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Proposal to Delay Docker Removal From Fuel Master Node
;>>>>> +1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> Bulat Gaifullin >>>>>>>> Mirantis Inc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 15 Dec 2015, at 22:19, Andrew Maksimov <amaksi...@mirantis.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> Regards, >>>>>>>> Andrey Maximov >>>>>>>> Fuel Project Manager >>>>>>>> >>>>>>>> On Tue, Dec 15, 2015 at 9:41 PM, Vladimir Kuklin < >>>>>>>> vkuk...@mirantis.com> wrote: >>>>>>>> >>>>>>>>> Folks >>>>>>>>> >>>>>>>>> This email is a proposal to push Docker containers removal from >>>>>>>>> the master node to the date beyond 8.0 HCF. >>>>>>>>> >>>>>>>>> Here is why I propose to do so. >>>>>>>>> >>>>>>>>> Removal of Docker is a rather invasive change and may introduce a >>>>>>>>> lot of regressions. It is well may affect how bugs are fixed - we >>>>>>>>> might >>>>>>>>> have 2 ways of fixing them, while during SCF of 8.0 this may affect >>>>>>>>> velocity of bug fixing as you need to fix bugs in master prior to >>>>>>>>> fixing >>>>>>>>> them in stable branches. This actually may significantly increase our >>>>>>>>> bugfixing pace and put 8.0 GA release on risk. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Yours Faithfully, >>>>>>>>> Vladimir Kuklin, >>>>>>>>> Fuel Library Tech Lead, >>>>>>>>> Mirantis, Inc. >>>>>>>>> +7 (495) 640-49-04 >>>>>>>>> +7 (926) 702-39-68 >>>>>>>>> Skype kuklinvv >>>>>>>>> 35bk3, Vorontsovskaya Str. >>>>>>>>> Moscow, Russia, >>>>>>>>> www.mirantis.com <http://www.mirantis.ru/> >>>>>>>>> www.mirantis.ru >>>>>>>>> vkuk...@mirantis.com >>>>>>>>> >>>>>>>>> >>>>>>>>> __ >>>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>>> Unsubscribe: >>>>>>>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>>>>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> __ >>>>>>>> OpenStack Development 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> __ >>>>>>>> OpenStack Development 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> __ >>>>>>> OpenStack Development 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> __ >>>>>> OpenStack Development 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Yours Faithfully, >>>>> Vladimir Kuklin, >>>>> Fuel Library Tech Lead, >>>>> Mirantis, Inc. >>>>> +7 (495) 640-49-04 >>>>> +7 (926) 702-39-68 >>>>> Skype kuklinvv >>>>> 35bk3, Vorontsovskaya Str. >>>>> Moscow, Russia, >>>>> www.mirantis.com <http://www.mirantis.ru/> >>>>> www.mirantis.ru >>>>> vkuk...@mirantis.com >>>>> >>>>> >>>>> __ >>>>> OpenStack Development 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 >>>>> >>>>> >>>> >>>> >>>> __ >>>> OpenStack Development 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 >>>> >>>> >>> >>> >>> __ >>> OpenStack Development 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 >>> >>> >> >> __ >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] PostgreSQL 9.3 and JSON operations
e to make >> > >> JSON queries? So we can use different backends if necessary? >> > >> >> > >> Thanks, >> > >> - Igor >> > >> >> > >> On Tue, Dec 15, 2015 at 5:06 PM, Mike Bayer <mba...@redhat.com> >> > >> wrote: >> > >> > >> > >> > >> > >> > On 12/15/2015 07:20 AM, Igor Kalnitsky wrote: >> > >> >> Hey Julien, >> > >> >> >> > >> >>> >> > >> >>> >> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql >> > >> >> >> > >> >> I believe this blueprint is about DB for OpenStack cloud (we use >> > >> >> Galera now), while here we're talking about DB backend for Fuel >> > >> >> itself. Fuel has a separate node (so called Fuel Master) and we >> > >> >> use PostgreSQL now. >> > >> >> >> > >> >>> does that mean Fuel is only going to be able to run with >> > >> >>> PostgreSQL? >> > >> >> >> > >> >> Unfortunately we already tied up to PostgreSQL. For instance, >> > >> >> we use PostgreSQL's ARRAY column type. Introducing JSON column >> > >> >> is one more way to tighten knots harder. >> > >> > >> > >> > actually not. if you replace your ARRAY columns with JSON >> > >> > entirely, MySQL has JSON as well now: >> > >> > https://dev.mysql.com/doc/refman/5.7/en/json.html >> > >> > >> > >> > there's already a mostly finished PR for SQLAlchemy support in >> > >> > the queue. >> > >> > >> > >> > >> > >> > >> > >> >> >> > >> >> - Igor >> > >> >> >> > >> >> On Tue, Dec 15, 2015 at 12:28 PM, Julien Danjou >> > >> >> <jul...@danjou.info> wrote: >> > >> >>> On Mon, Dec 14 2015, Igor Kalnitsky wrote: >> > >> >>> >> > >> >>>> The things I want to notice are: >> > >> >>>> >> > >> >>>> * Currently we aren't tied up to PostgreSQL 9.3. >> > >> >>>> * There's a patch [2] that ties Fuel up to PostgreSQL 9.3+ by >> > >> >>>> using a set of JSON operations. >> > >> >>> >> > >> >>> I'm curious and have just a small side question: does that >> > >> >>> mean Fuel is >> > >> >>> only going to be able to run with PostgreSQL? >> > >> >>> >> > >> >>> I also see >> > >> >>> >> > >> >>> >> https://blueprints.launchpad.net/fuel/+spec/openstack-ha-fuel-postgresql, >> > >> >>> maybe it's related? >> > >> >>> >> > >> >>> Thanks! >> > >> >>> >> > >> >>> -- >> > >> >>> Julien Danjou >> > >> >>> // Free Software hacker >> > >> >>> // https://julien.danjou.info >> > >> >> >> > >> >> >> > >> >> >> __ >> > >> >> OpenStack Development 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 >> > >> >> >> > >> > >> > >> > >> > >> > >> __ >> > >> > OpenStack Development 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 >> > >> >> > >> >> __ >> > >> OpenStack Development 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 >> > > >> > > >> > > >> > > >> > > -- >> > > Yours Faithfully, >> > > Vladimir Kuklin, >> > > Fuel Library Tech Lead, >> > > Mirantis, Inc. >> > > +7 (495) 640-49-04 >> > > +7 (926) 702-39-68 >> > > Skype kuklinvv >> > > 35bk3, Vorontsovskaya Str. >> > > Moscow, Russia, >> > > www.mirantis.com >> > > www.mirantis.ru >> > > vkuk...@mirantis.com >> > > >> > > >> __ >> > > OpenStack Development 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 >> > > >> > >> > >> __ >> > OpenStack Development 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 >> >> >> >> -- >> Thanks, >> Dmitry Teselkin >> >> >> __ >> OpenStack Development 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 >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze Exceptions
Latest update: all implemented now. Task-based deployment was the last one, and it got merged today: http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html . Great work everyone! On Fri, Dec 11, 2015 at 12:48 PM Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: > Hi all, > > On Wed, Dec 2, 2015 at 7:47 PM, Mike Scherbakov <mscherba...@mirantis.com> > wrote: > >> Hi all, >> we ran a meeting and made a decision on feature freeze exceptions. Full >> log is here: >> https://etherpad.openstack.org/p/fuel-8.0-FF-meeting >> >> The following features were granted with feature freeze exception: >> >>1. CentOS 7. ETA: Monday 7th. Blueprint: >>https://blueprints.launchpad.net/fuel/+spec/master-on-centos7. We >>have rather complicated plan on merges here: >> >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html >> >> > All patches has been merged. > >> >>1. Disable queue mirroring for RPC queues in RabbitMQ. ETA: didn't >>define. As fairly small patch is related, I propose Monday, 7th to be the >>last day. >> >> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc >> >> I have just merged the last patch as it's turned off by default. It > doesn't change the current behaviour but gives a perfect chance to turn on > this experimental feature to adjust our reference architecture in 9.0 > >> >>1. Task based deployment with Astute. ETA: Friday, 11th. >>https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute. >>Decision is that new code must be disabled by default. >> >> The most of patches have been merged. There is one patch in nailgun and > one patch in library (just splitting task into 2 tasks). > >> >>1. Component Registry. ETA: Wednesday, 10th. Only >>https://review.openstack.org/#/c/246889/ is given with an exception. >>BP: https://blueprints.launchpad.net/fuel/+spec/component-registry >> >> All patches have been merged. > >> >>1. Add vmware cluster after deployment. ETA: Tuesday, 8th. Only this >>patch is given with an exception: >>https://review.openstack.org/#/c/251278/. BP: >>https://blueprints.launchpad.net/fuel/+spec/add-vmware-clusters >> >> All patches have been merged. > >> >>1. Support murano service broker. ETA: Tuesday, 8th. Only this patch >>is given an exception: https://review.openstack.org/#/c/252356. BP: >> >> https://blueprints.launchpad.net/fuel/+spec/implement-support-for-murano-service-broker >> >> All patches have been merged. > >> >>1. Ubuntu boostrap. Two patches requested for FFE: >>https://review.openstack.org/#/c/250504/, >>https://review.openstack.org/#/c/251873/. Both are merged. So I >>consider that this is actually done. >> >> All patches have been merged. > > >> I'm calling everyone to update blueprints status. I'm volunteering to go >> over open blueprints targeting 8.0 tomorrow, and move all which are not in >> "Implemented" status unless those are exceptions or test/docs related >> things. >> >> I have moved statuses to 'Implemented', though we need to continue > working on documentation, auto-tests and bugs. > > Thanks all for keeping a focused efforts on getting code into master. I >> strongly suggest that we don't push any exception further down, and if >> something is not done by second deadline - it has to be disabled / reverted >> in 8.0. >> > > Thank you all for helping to get this done. Let's focus on bugs together > to take the quality to the next level. > > >> -- >> Mike Scherbakov >> #mihgen >> >> __ > > >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze Exceptions
Update after today's IRC meeting [1]: [1] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-12-10-16.00.html 1. [MERGED] CentOS 7. ETA: Monday 7th. Blueprint: https://blueprints.launchpad.net/fuel/+spec/master-on-centos7. 2. [MOVED to 9.0] Disable queue mirroring for RPC queues in RabbitMQ. https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc 3. [In progress] Task based deployment with Astute. ETA: Friday, 11th. https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute. Decision is that new code must be disabled by default. 4. [MERGED] Component Registry. ETA: Wednesday, 10th. Only https://review.openstack.org/#/c/246889/ is given with an exception. BP: https://blueprints.launchpad.net/fuel/+spec/component-registry 5. [MERGED] Add vmware cluster after deployment. ETA: Tuesday, 8th. Only this patch is given with an exception: https://review.openstack.org/#/c/251278/. BP: https://blueprints.launchpad.net/fuel/+spec/add-vmware-clusters 6. [MERGED] Support murano service broker. ETA: Tuesday, 8th. Only this patch is given an exception: https://review.openstack.org/#/c/252356. BP: https://blueprints.launchpad.net/fuel/+spec/implement-support-for-murano-service-broker 7. [MERGED] Ubuntu boostrap. Two patches requested for FFE: https://review.openstack.org/#/c/250504/, https://review.openstack.org/#/c/251873/. Both are merged. So I consider that this is actually done. It's unfortunate that we were not able to complete "disable rabbitmq mirroring". Let's make sure that we land it as soon as master opens for new release. I'm especially excited to see that we were able to get CentOS 7 support, as the most challenging thing! On Wed, Dec 2, 2015 at 10:47 AM Mike Scherbakov <mscherba...@mirantis.com> wrote: > Hi all, > we ran a meeting and made a decision on feature freeze exceptions. Full > log is here: > https://etherpad.openstack.org/p/fuel-8.0-FF-meeting > > The following features were granted with feature freeze exception: > >1. CentOS 7. ETA: Monday 7th. Blueprint: >https://blueprints.launchpad.net/fuel/+spec/master-on-centos7. We have >rather complicated plan on merges here: > > http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html >2. Disable queue mirroring for RPC queues in RabbitMQ. ETA: didn't >define. As fairly small patch is related, I propose Monday, 7th to be the >last day. > > https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc >3. Task based deployment with Astute. ETA: Friday, 11th. >https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute. >Decision is that new code must be disabled by default. >4. Component Registry. ETA: Wednesday, 10th. Only >https://review.openstack.org/#/c/246889/ is given with an exception. >BP: https://blueprints.launchpad.net/fuel/+spec/component-registry >5. Add vmware cluster after deployment. ETA: Tuesday, 8th. Only this >patch is given with an exception: >https://review.openstack.org/#/c/251278/. BP: >https://blueprints.launchpad.net/fuel/+spec/add-vmware-clusters >6. Support murano service broker. ETA: Tuesday, 8th. Only this patch >is given an exception: https://review.openstack.org/#/c/252356. BP: > > https://blueprints.launchpad.net/fuel/+spec/implement-support-for-murano-service-broker >7. Ubuntu boostrap. Two patches requested for FFE: >https://review.openstack.org/#/c/250504/, >https://review.openstack.org/#/c/251873/. Both are merged. So I >consider that this is actually done. > > I'm calling everyone to update blueprints status. I'm volunteering to go > over open blueprints targeting 8.0 tomorrow, and move all which are not in > "Implemented" status unless those are exceptions or test/docs related > things. > > Thanks all for keeping a focused efforts on getting code into master. I > strongly suggest that we don't push any exception further down, and if > something is not done by second deadline - it has to be disabled / reverted > in 8.0. > -- > Mike Scherbakov > #mihgen > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Moved blueprints out of 8.0
Hi all, I've moved the following blueprints: https://etherpad.openstack.org/p/fuel-moved-bps-from-8.0 I called for blueprints status update at [1], [2], [3], [4], and suggested to move those which are not "Implemented". Now I finally did, except test/doc related (which can be done after FF). I think I moved a few which already implemented, as far as I'm aware of. For instance: https://blueprints.launchpad.net/fuel/+spec/master-on-centos7 https://blueprints.launchpad.net/fuel/+spec/dynamically-build-bootstrap https://blueprints.launchpad.net/fuel/+spec/package-for-js-modules https://blueprints.launchpad.net/fuel/+spec/component-registry If those are in fact done, please move them back, and set proper status. There is uncertainty to what to do with those parent blueprints, like ubuntu bootstrap one, which have incomplete test- and docs- related. My suggestion would be to set status "Deployment" and move them back to 8.0, if all coding is done. Once dependent test/docs are done, parent blueprint should be updated and become "Implemented". Thank you, [1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081047.html [2] https://etherpad.openstack.org/p/fuel-8.0-FF-meeting, line 428 [3] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html [4] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-12-10-16.00.log.html, 16:32 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Christmas Core Cleanup
Igor, thank you for driving this. I think that this is a great practice: we need to keep list of cores up to date. What about other repos, not mentioned here? Are those are fine being as is? What about fuel-docs, for instance? For instance, I see that Irina was able to provide just 5 reviews over 3 month period [1]. So I suspect that she can't pay that much of an attention to docs now.. Vitaly Kramskikh had 3 reviews, but I don't think is core in that particular repo (he is core in fuel-web repo). I'm not sure how stackalytics tracks that. [1] http://stackalytics.com/report/contribution/fuel-docs/90 Thanks, On Thu, Dec 10, 2015 at 8:12 AM Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Hi Evgeniy, > > Yes, you absolutely right! I as far as possible will ask them to > review certain patches (if they have no time to watch all patches_. > Moreover, I'm going to add them to MAINTAINERS file. > > Thanks, > Igor > > P.S: I hope you and others will manage to spend more time on Fuel, > since your feedback guys are really appreciated since you're proven > authorities here. ;) > > > On Thu, Dec 10, 2015 at 5:59 PM, Evgeniy L <e...@mirantis.com> wrote: > > Hi, > > > > Thank you Igor for cleaning core related groups. > > > > Also I would like to add that many of removed cores are still SME > (subject > > matter experts) > > in specific areas, so they will continue reviewing related patches. > > > > Thanks, > > > > On Thu, Dec 10, 2015 at 2:42 PM, Igor Kalnitsky <ikalnit...@mirantis.com > > > > wrote: > >> > >> Hey folks, > >> > >> In an effort to do some housekeeping, I clean up the list of core > >> reviewers in Fuel. > >> > >> According to Stackalytics the following cores show a low contribution > >> rate: > >> > >> # fuel-web [1] > >> > >> * Dmitry Shulyak > >> * Evgeniy L > >> > >> # python-fuelclient [2] > >> > >> * Dmitry Pyzhov > >> * Evgeniy L > >> > >> # shotgun [3] > >> > >> * Dmitry Shulyak > >> * Evgeniy L > >> > >> # fuel-upgrade [4] > >> > >> * Aleksey Kasatkin > >> * Vladimir Kozhukalov > >> > >> # fuel-main [5] > >> > >> * Dmitry Pyzhov > >> * Roman Vyalov > >> > >> # fuel-agent [6] > >> > >> * Aleksey Kasatkin > >> * Evgeniy L > >> * Igor Kalnitsky > >> > >> Also, I've removed Sebastian Kalinowski as he said he has no time to > >> work on Fuel anymore. > >> > >> Once former cores show high level of contribution again, I'll gladly > >> add them back. > >> > >> - Igor > >> > >> [1] http://stackalytics.com/report/contribution/fuel-web/90 > >> [2] http://stackalytics.com/report/contribution/python-fuelclient/90 > >> [3] http://stackalytics.com/report/contribution/shotgun/90 > >> [4] http://stackalytics.com/report/contribution/fuel-upgrade/90 > >> [5] http://stackalytics.com/report/contribution/fuel-main/90 > >> [6] http://stackalytics.com/report/contribution/fuel-agent/90 > >> > >> > __ > >> OpenStack Development 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 > > > > > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Extend FFE for "Disable queue mirroring for RPC queues in RabbitMQ"
Hi Dmitry, as much as I support the change, and glad that we got time for it, my opinion is that we should not extend a FFE. I have following reasons to think this way: 1) Feature Freeze is time based milestone, with the rational "FF ensures that sufficient share of the ReleaseCycle is dedicated to QA, until we produce the first release candidates. Limiting the changes that affect the behavior of the software allow for consistent testing and efficient bugfixing" [1]. Even though this feature will be disabled by default, it is important to note the first part of this rationale - we need to focus on stability now, not on features. 2) 7 FFEs for Fuel [2] I'd subjectively consider as high number, as in total there are ~25 major blueprints to be delivered. Dmitry, our PTL, unfortunately is absent for a couple of weeks, but his opinion is quite similar: "The list of exceptions is much longer than I'd like, and some have larger impact than I'd like, lets all of us make sure we don't come to regret granting these exceptions." [3]. Taking any exception further means moving FF, in fact. That means moving of release date, which I don't think we should even consider doing. 3) Exception to exception, in my opinion, should only be allowed in extremely rare cases for essential features only. When it becomes clear that the whole release has a major gap or serious issue, which can only be resolved by finishing an essential feature. I have no evidence to think that this functionality, which will be disabled by default, can fall into this category. 4) Changeset [4] has a change to the packaging spec. Any small change to packaging after FF imposes additional risk, as there is no good test automation for such kind of changes. Even if it's just include of a new file. In case of regression, we may easily lose a day for figuring out what is wrong and reverting a change. I'd like to hear component leads while PTL is absent these days [1] https://wiki.openstack.org/wiki/FeatureFreeze [2] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html [3] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081149.html [4] https://review.openstack.org/#/c/249180/ On Mon, Dec 7, 2015 at 2:30 PM Adam Heczko <ahec...@mirantis.com> wrote: > Hello Dmitry, > I like this idea and very much appreciate it. > +1 from me :) > > A. > > On Mon, Dec 7, 2015 at 9:48 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> Hello folks, >> >> I'd like to request extension of current FFE for the feature [1]. During >> the three FFE days we merged the spec [2] after big discussion and made a >> couple iterations over the implementation [3]. We had a chat with Bogdan on >> how to progress and here are the action items still need to be done: >> * part of the change responsible for RabbitMQ policy need to be >> upstreamed first to RabbitMQ repo. >> * the change needs to be review and merged by our library folks. >> >> Overall I think that 2-3 more days should be enough to finish it. >> >> What do you think folks? >> >> Dmitry >> >> [1] >> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc >> [2] https://review.openstack.org/247517 >> [3] https://review.openstack.org/249180 >> >> __ >> OpenStack Development 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 >> >> > > > -- > Adam Heczko > Security Engineer @ Mirantis Inc. > ______ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] FFE for Ubuntu bootstrap
Dmitry, thank you for clarification of a status. In a meeting we had [1], I misinterpreted a status of a feature is being fully completed, and that is what I reflected in my FFEs post [2]. I'm not sure if we have definition of done written for Fuel specifically, but my expectation from the spec [3] was that Ubuntu bootstrap has to be default option. That means that all related code has to be merged. One of the patches you've mentioned goes on since November, 27 and I'm not sure how long would it take to complete it. It is not a simple switch in a config file as I'd expect to see. It's not a 100+ LOC changeset in very core either, so I call for Matt as a maintainer [4] and core reviewers to assess a situation. My perspective is that we can test it right now without this patch and steps to do so are known [6], so feature is actually nearly complete except of additional action in fuel-menu. I hope that we could go an extra mile here and maintainer / cores could help with the patch. I don't personally think that we could go on without having a clear deadline for when it will be enabled. Even if [4] is merged, but ubuntu is not a default - I see a serious risks here, as majority of our automated tests and lots of manual tests done by random people will still be using another image, thus significantly decreasing our chances to see regressions on time. I'd give it an exception till end of Tuesday (as of after CentOS 7 expected merges) for full enablement, and that should have a fix to critical issue [7]. [1] https://etherpad.openstack.org/p/fuel-8.0-FF-meeting [2] http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html [3] http://specs.fuel-infra.org/fuel-specs-master/specs/8.0/dynamically-build-bootstrap.html [4] https://review.openstack.org/#/c/250662/ [5] https://github.com/openstack/fuel-menu/blob/master/MAINTAINERS [6] https://bugs.launchpad.net/fuel/+bug/1522406/comments/3 [7] https://bugs.launchpad.net/fuel/+bug/1522406 <https://bugs.launchpad.net/fuel/+bug/1522406/comments/3> On Thu, Dec 3, 2015 at 10:59 AM Dmitry Klenov <dkle...@mirantis.com> wrote: > Hi folks, > > Let me clarify the situation with Ubuntu bootstrap feature. > > First of all, I would like to highlight that all functional commits for > this feature were merged. This means that starting from yesterday everyone > has an ability to switch to Ubuntu-based bootstrap manually and start using > it. So I do not see the risk in loosing testing cycles in the community. > > The item which brought concerns on today status meeting was the enablement > of the feature by default. To do it, 2 patches have to be merged together: > * https://review.openstack.org/#/c/250662/ - main switch. > * https://review.openstack.org/#/c/251908/ - compatibility commit to QA > suite to comply with new bootstrap config format. > > I would like to raise the question if we can have a feature freeze > exception for these 2 patches? > > There are a couple of reasons why I consider it safer to merge these > patches several days later: > * There is a bug caught today which will block the tests to pass if we > switch to Ubuntu bootstrap by default: > https://bugs.launchpad.net/fuel/+bug/1522406 > * There were concerns that a lot of FF commit merges can bring instability > to QA suite. So it might be reasonable not to bring one more variable right > now and to enable ubuntu bootstrap by default when all automated tests are > stabilized. > > I would like to ask engineering and QA leads to express their ideas on > this. > > Thanks, > Dmitry. > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] CentOS7 Merging Plan
of all, someone from CI and QA teams should commit to monitoring > > the CentOS7 swarm run and report the results as soon as possible. > > Based on the results (which once again must be available by 17:00 > > MSK), we can decide on the final step of the plan. > > > > Decision point 4: Keep or revert > > > > If CentOS7 based swarm shows significant regression, we have to spend > > the rest of the weekend including Sunday reverting all CentOS7 commits > > that were merged during merge freeze. Once revert is completed, we > > will lift the merge freeze. > > > > If 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 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, and someone from CI will have to work a few hours on Sunday. > > > > > > -- > Thanks, > Dmitry Teselkin > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze is soon
Thank you all for participation. I'll write up a summary here in the next few hours. IRC log is unfortunately totally useless [1] due to freenode issues. Please help me to get the full log here: https://etherpad.openstack.org/p/fuel-8.0-FF-meeting [1] http://irclog.perlgeek.de/fuel-dev/2015-12-02 Thanks, On Wed, Dec 2, 2015 at 6:37 AM Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Sheena, > > Yeah, we will have a meeting in #fuel-dev IRC channel. :) > > - Igor > > On Wed, Dec 2, 2015 at 4:25 PM, Sheena Gregson <sgreg...@mirantis.com> > wrote: > > Is the meeting at 8am PST today? > > > > > > > > From: Mike Scherbakov [mailto:mscherba...@mirantis.com] > > Sent: Wednesday, December 02, 2015 1:57 AM > > To: OpenStack Development Mailing List (not for usage questions) > > <openstack-dev@lists.openstack.org> > > Subject: Re: [openstack-dev] [Fuel] Feature Freeze is soon > > > > > > > > In order to be effective, I created an etherpad to go over: > > > > https://etherpad.openstack.org/p/8.0-features-status > > > > > > > > I'd like to call everyone to update status of blueprints, so that we can > > have accurate picture of 8.0 deliverables. During the meeting, I'd like > us > > to quickly sync on FFEs and clarify status of major blueprints (if it > won't > > be updated by some reason). > > > > > > > > In fact, we'd need to go over two first sections of etherpad (around 15 > > items now). I assume that 1 hour will be enough, and ideally to go > quicker. > > If I'm missing anything believed to be major, please move it in there. > > > > > > > > Thanks, > > > > > > > > On Tue, Dec 1, 2015 at 1:37 AM Vladimir Kuklin <vkuk...@mirantis.com> > wrote: > > > > Mike I think, it is rather good idea. I guess we can have a couple of > > requests still - although everyone is shy, we might get a little storm of > > FFE's. BTW, I will file at least one. > > > > > > > > On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov < > mscherba...@mirantis.com> > > wrote: > > > > Hi Fuelers, > > > > we are couple of days away from FF [1]. I have not noticed any request > for > > feature freeze exception, so I assume that we pretty much decided what is > > going into 8.0 and what is not. > > > > > > > > If there are items which we'd like to ask exception for, I'd like us to > have > > this requested now - so that we all can spend some time on analysis of > what > > is done and what is left, and on risks assessment. I'd suggest to not > > consider any exception requests on the day of FF, as it doesn't leave us > > time to spend on it. > > > > > > > > To make a formal checkpoint of what is in and what is out, I suggest to > get > > together on FF day, Wednesday, and go over all the items we have been > > working on in 8.0. What do you think folks? For instance, in #fuel-dev > IRC > > at 8am PST (4pm UTC)? > > > > > > > > [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule > > > > -- > > > > Mike Scherbakov > > #mihgen > > > > > > > > > __ > > OpenStack Development 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 > > > > > > > > > > > > -- > > > > Yours Faithfully, > > Vladimir Kuklin, > > Fuel Library Tech Lead, > > Mirantis, Inc. > > +7 (495) 640-49-04 > > +7 (926) 702-39-68 > > Skype kuklinvv > > 35bk3, Vorontsovskaya Str. > > Moscow, Russia, > > www.mirantis.com > > www.mirantis.ru > > vkuk...@mirantis.com > > > > > __ > > OpenStack Development 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 > > > > -- > > > > Mike Scherbakov > > #mihgen > > > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze Exception Request: Task Based Deployment in Astute
t; Fuel > > user experience. > > > > * Additional Cons of the Feature > > > > Moreover, this feature improves how the following use cases are also > > addressed: > > > > 1. When user deploys a specific set of nodes or tasks > > It will be possible to introduce additional flag for deploy/task run > handler > > for Nailgun to pick up dependencies of specified tasks, even if they are > > currently not in place in current deployment graph. This means that > instead > > of running > > > > fuel nodes --node-id 2,3 --deploy > > > > and see how it fails as node-1 contains some of the tasks that are > required > > by nodes 2 and 3, user will be calm about it as he will be able to > specify > > an option to populate deployment flow with needed tasks. No more > > > > fuel nodes --node-id 2 --tasks netconfig -> Fail, because you forgot to > > specify some of the required tasks, e.g. hiera, globals. > > > > 2. Post-deployment plugin installation > > > > This feature also makes post-deployment plugin installation much easier > as > > plugin installation will happen almost in matter of minutes instead of > > hours. > > > > 3. Cluster re-deployment for some of LCM cases support > > > > Whenever user can change settings on the nodes and trigger full cluster > > redeployment or whenever he wants to get tainted cluster converge back to > > the previous state deployed by Fuel, he will get his cluster back into > > operational state in 30 minutes. > > > > 4. Better capabilities for separated services plugins > > > > Task-based approach allows one to deploy things with separate services in > > much more flexible ways. E.g one will not have to introduce 2 roles in > the > > plugin for controller to detach keystone services, e.g. > > pre-keystone-controller-tasks and post-keystone-controller-tasks. All he > > will need is to introduce "skipped" keystone task for controllers so that > > keystone is deployed only on the node with keystone role. > > > > * Merge plan > > > > Merge Astute changes - ETA Dec 4rd > > Merge Nailgun changes - ETA Dec 4rd > > Prepare Fuel Library changes - ETA Dec 3rd > > Test this feature on Scale Lab and against swarm - ETA SCF > > Make decision whether to enable task-based deployment engine by default - > > SCF > > > > * Summary > > > > This feature brings a lot of benefits for everyone. Its current > > implementation introduces 0 chances for regressions as it will be > disabled > > by default and it will require specific actions for a user to start using > > this feature. In meanwhile we will test this feature at Scale Lab and > > against swarm and custom tests. And by SCF we may decide whether to > switch > > to it based on the reported results. If it happens before SCF, we will be > > able to significantly ramp up our development and bugfixing velocity. > > > > -- > > Yours Faithfully, > > Vladimir Kuklin, > > Fuel Library Tech Lead, > > Mirantis, Inc. > > +7 (495) 640-49-04 > > +7 (926) 702-39-68 > > Skype kuklinvv > > 35bk3, Vorontsovskaya Str. > > Moscow, Russia, > > www.mirantis.com > > www.mirantis.ru > > vkuk...@mirantis.com > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Feature Freeze Exceptions
Hi all, we ran a meeting and made a decision on feature freeze exceptions. Full log is here: https://etherpad.openstack.org/p/fuel-8.0-FF-meeting The following features were granted with feature freeze exception: 1. CentOS 7. ETA: Monday 7th. Blueprint: https://blueprints.launchpad.net/fuel/+spec/master-on-centos7. We have rather complicated plan on merges here: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081026.html 2. Disable queue mirroring for RPC queues in RabbitMQ. ETA: didn't define. As fairly small patch is related, I propose Monday, 7th to be the last day. https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc 3. Task based deployment with Astute. ETA: Friday, 11th. https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute. Decision is that new code must be disabled by default. 4. Component Registry. ETA: Wednesday, 10th. Only https://review.openstack.org/#/c/246889/ is given with an exception. BP: https://blueprints.launchpad.net/fuel/+spec/component-registry 5. Add vmware cluster after deployment. ETA: Tuesday, 8th. Only this patch is given with an exception: https://review.openstack.org/#/c/251278/. BP: https://blueprints.launchpad.net/fuel/+spec/add-vmware-clusters 6. Support murano service broker. ETA: Tuesday, 8th. Only this patch is given an exception: https://review.openstack.org/#/c/252356. BP: https://blueprints.launchpad.net/fuel/+spec/implement-support-for-murano-service-broker 7. Ubuntu boostrap. Two patches requested for FFE: https://review.openstack.org/#/c/250504/, https://review.openstack.org/#/c/251873/. Both are merged. So I consider that this is actually done. I'm calling everyone to update blueprints status. I'm volunteering to go over open blueprints targeting 8.0 tomorrow, and move all which are not in "Implemented" status unless those are exceptions or test/docs related things. Thanks all for keeping a focused efforts on getting code into master. I strongly suggest that we don't push any exception further down, and if something is not done by second deadline - it has to be disabled / reverted in 8.0. -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][FFE] Component registry
ETA Wednesday, 10th Summary of meeting: http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html On Wed, Dec 2, 2015 at 10:07 AM Igor Kalnitsky <ikalnit...@mirantis.com> wrote: > Fuelers, > > As we decided on today's IRC meeting in #fuel-dev, FFE is granted for > 1 week only. > > Thanks, > igor > > On Wed, Dec 2, 2015 at 5:42 PM, Andrian Noga <an...@mirantis.com> wrote: > > Colleagues, > > > > Folks, > > I would like to request feature freeze exception for Component registry > > https://blueprints.launchpad.net/fuel/+spec/component-registry > > > > Specification is already merged https://review.openstack.org/#/c/229306/ > > Main patch is also merged https://review.openstack.org/#/c/247913/ > > We still need to merge UI changes > https://review.openstack.org/#/c/246889/53 > > The change itself is a very small patch. > > That should take just several days, so if there will be no other > > objections, we will be able to merge the change in a week timeframe. > > > > Regards, > > Andrian Noga > > Project manager > > Partners Centric Engineering Team, > > Mirantis, Inc. > > +38 (063) 966-21-24 > > Skype: bigfoot_ua > > www.mirantis.com > > an...@mirantis.com > > > > > __ > > OpenStack Development 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 > > > > ______ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7
Based on time of this request, you seem to be late to the party... FF is in action. Formally it was requested before FF, but as I mentioned in my email [1], we'd need at least a day for consider exception and assess related risks. Filing it couple of hours before FF doesn't give a chance to do it. Any other opinions? [1] http://lists.openstack.org/pipermail/openstack-dev/2015-December/080895.html On Wed, Dec 2, 2015 at 9:52 AM Artem Silenkov <asilen...@mirantis.com> wrote: > Hello! > > We have got > - erlang=18.1 https://review.fuel-infra.org/#/c/12896/ > - rabbitmq-server=3.5.6 https://review.fuel-infra.org/#/c/12901/ > packaged for ubuntu trusty in corresponding requests. > > Those requests are not merged yet but probably would today evening. > We need some time to backport it for centos7 in order to keep versions > synced. > > It is not rocket science to package it for centos7 and it could take not > more then one working day. > This work could be done as soon as ubuntu packages are landed. > > Regards, > Artem Silenkov > --- > MOS~Packaging > mirantis.com > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Feature Freeze is soon
In order to be effective, I created an etherpad to go over: https://etherpad.openstack.org/p/8.0-features-status I'd like to call everyone to update status of blueprints, so that we can have accurate picture of 8.0 deliverables. During the meeting, I'd like us to quickly sync on FFEs and clarify status of major blueprints (if it won't be updated by some reason). In fact, we'd need to go over two first sections of etherpad (around 15 items now). I assume that 1 hour will be enough, and ideally to go quicker. If I'm missing anything believed to be major, please move it in there. Thanks, On Tue, Dec 1, 2015 at 1:37 AM Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Mike I think, it is rather good idea. I guess we can have a couple of > requests still - although everyone is shy, we might get a little storm of > FFE's. BTW, I will file at least one. > > On Tue, Dec 1, 2015 at 10:28 AM, Mike Scherbakov <mscherba...@mirantis.com > > wrote: > >> Hi Fuelers, >> we are couple of days away from FF [1]. I have not noticed any request >> for feature freeze exception, so I assume that we pretty much decided what >> is going into 8.0 and what is not. >> >> If there are items which we'd like to ask exception for, I'd like us to >> have this requested now - so that we all can spend some time on analysis of >> what is done and what is left, and on risks assessment. I'd suggest to not >> consider any exception requests on the day of FF, as it doesn't leave us >> time to spend on it. >> >> To make a formal checkpoint of what is in and what is out, I suggest to >> get together on FF day, Wednesday, and go over all the items we have been >> working on in 8.0. What do you think folks? For instance, in #fuel-dev IRC >> at 8am PST (4pm UTC)? >> >> [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule >> -- >> Mike Scherbakov >> #mihgen >> >> __ >> OpenStack Development 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 >> >> > > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru > vkuk...@mirantis.com > ______ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror
Vladimir, if you've been behind of this, could you please share further plans in separate email thread or (better) provide plans in README in the repo, so everyone can be aware of planned changes and can review them too? If you or someone else propose a change, please post a link here... Thanks, On Tue, Dec 1, 2015 at 6:27 AM Vladimir Kozhukalov <vkozhuka...@mirantis.com> wrote: > Thomas, > > You are right about two independent modules in the repo. That is because > the former intention was to get rid of fuel-mirror (and fuel-createmirror) > and perestroika and leave only packetary there. Packetary is to be > developed so it is able to build not only repositories but packages as > well. So we'll be able to remove perestroika once it is ready. Two major > capabilities of fuel-mirror are: > 1) create mirror (and partial mirror) and packetary can be used for this > instead > 2) apply mirror to nailgun (which is rather a matter of python-fuelclient) > So fuel-mirror also should be removed in the future to avoid functionality > duplication. > > Those were the reasons not to put them separately. (C) "There can be only > one". > > > > > > Vladimir Kozhukalov > > On Tue, Dec 1, 2015 at 1:25 PM, Thomas Goirand <z...@debian.org> wrote: > >> On 12/01/2015 09:25 AM, Mike Scherbakov wrote: >> > 4. I don't quite understand how repo is organized. I see a lot of >> > Python code regarding to fuel-mirror itself and packetary, which is >> > used as fuel-mirrors core and being written and maintained mostly by >> > Bulat [5]. There are seem to be bash scripts now related to >> > Perestroika, and. I don't quite get how these things relate each to >> > other, and if we expect core reviewers to be merging code into both >> > Perestroika and Packetary? Unless mission of repo, code gets clear, >> > I'd abstain from giving +1... >> >> Also, why isn't packetary living in its own repository? It seems wrong >> to me to have 2 python modules living in the same source repo, unless >> they share the same egg-info. It feels weird to have to call setup.py >> install twice in the resulting Debian source package. That's not how >> things are done elsewhere, and I'd like to avoid special cases, just >> because it's fuel... >> >> Cheers, >> >> Thomas Goirand (zigo) >> >> >> __ >> OpenStack Development 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 >> > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Nominating Dmitry Burmistrov to core reviewers of fuel-mirror
-1 I personally know Dmitry and respect his contributions into our package management and CI systems around it. Thanks to Dmitry, a lot of bad things were prevented and many things developed which work very well. However, I don't particularly understand this proposal, and I'd like to get some clarifications. Even though I'm not a core in the repo, and far from being an expert in this area, I hope other active contributors will find my questions and concerns reasonable. I put -1 for the following reasons: 1. The most important - I'd suggest to wait until SCF [1], when we branch out stable/8.0 and reopen master for new features. Just risk management 2. Roman, are you part of core team for fuel-mirror? Unless I'm missing any Fuel-specific policy, [2] states this clear: "member of the existing core team can nominate" 3. Even though repo is fairly fresh, I'd question if numbers are good enough to become a core (17 reviews [3], 7 commits [4]) 4. I don't quite understand how repo is organized. I see a lot of Python code regarding to fuel-mirror itself and packetary, which is used as fuel-mirrors core and being written and maintained mostly by Bulat [5]. There are seem to be bash scripts now related to Perestroika, and. I don't quite get how these things relate each to other, and if we expect core reviewers to be merging code into both Perestroika and Packetary? Unless mission of repo, code gets clear, I'd abstain from giving +1... [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule [2] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess [3] http://stackalytics.com/report/contribution/fuel-mirror/180 [4] git log --oneline --author="Dmitry Burmistrov" | wc -l [5] https://github.com/openstack/fuel-mirror/blob/master/MAINTAINERS#L38 On Fri, Nov 27, 2015 at 6:29 AM Vitaly Parakhin <vparak...@mirantis.com> wrote: > +1 > > пятница, 27 ноября 2015 г. пользователь Roman Vyalov написал: > >> Hi all, >> Dmitry is doing great work and I hope our Perestroika build system will >> become even better. >> At the moment Dmitry is core developer in our Perestroika builds system. >> But he not core reviewer in gerrit repository. >> Fuelers, please vote for Dmitry >> > > > -- > Regards, > Vitaly Parakhin. > CI Engineer | Mirantis, Inc. | http://www.mirantis.com > IRC: brain461 @ chat.freenode.net | Slack: vparakhin > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?
Aleksey, can you clarify it? Why it can't be deployed? According to what I see at our fakeUI install [1], wizard allows to choose nova-network only in case if you choose vcenter. Do we support Neutron for vCenter already? If so - we could safely remove nova-network altogether. [1] http://demo.fuel-infra.org:8000/ On Mon, Nov 30, 2015 at 4:27 AM Aleksey Kasatkin <akasat...@mirantis.com> wrote: > This remains unclear. > Now, for 8.0, the Environment with Nova-Network can be created but cannot > be deployed (and its creation is tested in UI integration tests). > AFAIC, we should either remove the ability of creation of environments > with Nova-Network in 8.0 or return it back into working state. > > > Aleksey Kasatkin > > > On Fri, Oct 23, 2015 at 3:42 PM, Sheena Gregson <sgreg...@mirantis.com> > wrote: > >> As a reminder: there are no individual networking options that can be >> used with both vCenter and KVM/QEMU hypervisors once we deprecate >> nova-network. >> >> >> >> The code for vCenter as a stand-alone deployment may be there, but the >> code for the component registry ( >> https://blueprints.launchpad.net/fuel/+spec/component-registry) is still >> not complete. The component registry is required for a multi-HV >> environment, because it provides compatibility information for Networking >> and HVs. In theory, landing this feature will enable us to configure DVS + >> vCenter and Neutron with GRE/VxLAN + KVM/QEMU in the same environment. >> >> >> >> While Andriy Popyvich has made considerable progress on this story, I >> personally feel very strongly against deprecating nova-network until we >> have confirmed that we can support *all current use cases* with the >> available code base. >> >> >> >> Are we willing to lose the multi-HV functionality if something prevents >> the component registry work from landing in its entirety before the next >> release? >> >> >> >> *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] >> *Sent:* Friday, October 23, 2015 6:30 AM >> *To:* OpenStack Development Mailing List (not for usage questions) < >> openstack-dev@lists.openstack.org> >> *Subject:* Re: [openstack-dev] [Fuel] Remove nova-network as a >> deployment option in Fuel? >> >> >> >> Hi, >> >> >> >> As far as I know neutron code for VCenter is ready. Guys are still >> testing it. Keep patience... There will be announce soon. >> >> >> -- >> Best regards, >> Sergii Golovatiuk, >> Skype #golserge >> IRC #holser >> >> __ >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Feature Freeze is soon
Hi Fuelers, we are couple of days away from FF [1]. I have not noticed any request for feature freeze exception, so I assume that we pretty much decided what is going into 8.0 and what is not. If there are items which we'd like to ask exception for, I'd like us to have this requested now - so that we all can spend some time on analysis of what is done and what is left, and on risks assessment. I'd suggest to not consider any exception requests on the day of FF, as it doesn't leave us time to spend on it. To make a formal checkpoint of what is in and what is out, I suggest to get together on FF day, Wednesday, and go over all the items we have been working on in 8.0. What do you think folks? For instance, in #fuel-dev IRC at 8am PST (4pm UTC)? [1] https://wiki.openstack.org/wiki/Fuel/8.0_Release_Schedule -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [stackalytics] [metrics] Review metrics: average numbers
Jesus, thanks for sharing this. Looks like you've got quite comprehensive data analysis tool for code review. Is there a way to get Fuel added somehow.. ? Ilya, > Do you mean to calculate stats not only for open, but also for those that are already closed? Yes. I need to calculate stats for ALL, including already closed, for some period of time. For instance, last 30, 60, 90 days. btw, I updated list of fuel-group repos, please review: https://review.openstack.org/#/c/244936/. Thank you, On Thu, Nov 12, 2015 at 6:59 AM Ilya Shakhat <ishak...@mirantis.com> wrote: > Hi Mike, > > > Do I understand right, that average numbers >> > here are calculated out of open reviews, not total number of reviews? > > > Average numbers are calculated for reviews within the group. But I'd > expect them to be "time since the last vote", not "time when patch > proposed" as they do now. > > > > The most important number which I'm trying to get, is an average time >> > change requests waiting for reviewers since last vote or mark, from >> > all requests (not only those which remain in open state, like it is >> > now, I believe). > > > Do you mean to calculate stats not only for open, but also for those that > are already closed? Should it be for all times, or during specified period? > > Regards, > --Ilya > > > > 2015-11-12 1:14 GMT+03:00 Jesus M. Gonzalez-Barahona <j...@bitergia.com>: > >> Hi, Mike, >> >> I'm not sure what you are looking for exactly, but maybe you can have a >> look at the quarterly reports. AFAIK, currently there is none specific >> to Fuel, but for example for Nova, you have: >> >> http://activity.openstack.org/dash/reports/2015-q3/pdf/projects/nova.pd >> f >> <http://activity.openstack.org/dash/reports/2015-q3/pdf/projects/nova.pd%0Df> >> >> In page 6, you have "time waiting for reviewer" (from the moment a new >> patchset is produced, to the time a conclusive review vote is found in >> Gerrit), and "time waiting for developer" (from the conclusive review >> vote to next patchset). >> >> We're working now in a visualization for that kind of information. For >> now, we only have complete changeset values, check if you're >> interested: >> >> http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce >> ss-in-openstack/ >> <http://blog.bitergia.com/2015/10/22/understanding-the-code-review-proce%0Dss-in-openstack/> >> >> Saludos, >> >> Jesus. >> >> On Wed, 2015-11-11 at 21:45 +, Mike Scherbakov wrote: >> > Hi stackers, >> > I have a question about Stackalytics. >> > I'm trying to get some more data from code review stats. For Fuel, >> > for instance, >> > http://stackalytics.com/report/reviews/fuel-group/open >> > shows some useful stats. Do I understand right, that average numbers >> > here are calculated out of open reviews, not total number of reviews? >> > >> > The most important number which I'm trying to get, is an average time >> > change requests waiting for reviewers since last vote or mark, from >> > all requests (not only those which remain in open state, like it is >> > now, I believe). >> > >> > How hard would it be to get / extend Stackalytics to make it..? >> > >> > Thanks! >> > -- >> > Mike Scherbakov >> > #mihgen >> > _ >> > _ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs >> > cribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> -- >> Bitergia: http://bitergia.com >> /me at Twitter: https://twitter.com/jgbarah >> >> >> __ >> OpenStack Development 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 >> > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [stackalytics] Review metrics: average numbers
Hi stackers, I have a question about Stackalytics. I'm trying to get some more data from code review stats. For Fuel, for instance, http://stackalytics.com/report/reviews/fuel-group/open shows some useful stats. Do I understand right, that average numbers here are calculated out of open reviews, not total number of reviews? The most important number which I'm trying to get, is an average time change requests waiting for reviewers since last vote or mark, from all requests (not only those which remain in open state, like it is now, I believe). How hard would it be to get / extend Stackalytics to make it..? Thanks! -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Change VIP address via API
tis.com>
>>> wrote:
>>> > Hi folks,
>>> >
>>> > I'm working on the following story [1][2]:
>>> > API must allow VIP to be manually set to ANY valid IP address. If the
>>> IP on
>>> > update API is a member of any network in this environment then the
>>> address
>>> > should be put in the assignments table so that it can not be used in
>>> any
>>> > other
>>> > automatic assignment. (This allows the user to override if the
>>> automatic
>>> > allocation doesn't match their needs or in the case that they want to
>>> use
>>> > external LB).
>>> >
>>> > [1] https://bugs.launchpad.net/fuel/+bug/1482399
>>> > [2] https://review.openstack.org/230943
>>> >
>>> > So, I have the following proposal for now:
>>> > Add new url (e.g. /clusters//network_configuration/vips/
>>> ), use
>>> > GET
>>> > to query current VIPs info, use PUT to change VIPs addresses (set them
>>> > manually
>>> > or request to allocate them automatically).
>>> > Now VIPs have the following format in API requests data:
>>> > vips: [
>>> > {
>>> > 'network_role': 'management',
>>> > 'namespace': 'haproxy',
>>> > 'ipaddr': '10.10.10.10',
>>> > 'node_roles': ['controller']
>>> > },...
>>> > ]
>>> > So, 'ipaddr' field can be set to any (almost any) user-defined value
>>> or to
>>> > None (null in YAML).
>>> > When it is set to None, IP address will be allocated automatically.
>>> When the
>>> > user runs GET
>>> > request for the first time, all 'ipaddr' fields are equal to None. So,
>>> user
>>> > can set some (or all)
>>> > of them to desired values and run PUT. When the GET is run after PUT,
>>> all
>>> > addresses will be
>>> > filled with values. User can reset some of them to None or change to
>>> other
>>> > IP when required.
>>> > So, addresses will be re-allocated on the next PUT requests.
>>> > If address given by user overlaps with some of the allocated IPs, PUT
>>> > request will be rejected.
>>> > There is a question, what to do when the given address overlaps with
>>> the
>>> > network from another
>>> > environment? overlaps with the network of current environment which
>>> does not
>>> > match the
>>> > network role of the VIP?
>>> > My opinion that those should pass with a warning message.
>>> >
>>> > Please share your proposals and comments on this,
>>> >
>>> > Thanks,
>>> >
>>> >
>>> > Aleksey Kasatkin
>>> >
>>> >
>>> >
>>> __
>>> > OpenStack Development 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
>>> >
>>>
>>>
>>> __
>>> OpenStack Development 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
>>>
>>
>>
> __
> OpenStack Development 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
>
--
Mike Scherbakov
#mihgen
__
OpenStack Development 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
Re: [openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?
Hi all, I'm back to this thread. Who can take a lead here and remove nova-network starting from 8.0 and all following releases? On Thu, Oct 1, 2015 at 3:15 AM Sergii Golovatiuk <sgolovat...@mirantis.com> wrote: > Hi, > > Can we get the latest supported release version? We will remove from > nailgun after End of Life of that particular release... > > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] [CI] Running fuelclient tests against review requests for fuel-web repo
Can we do it in OpenStack Infra.. ? On Wed, Oct 21, 2015 at 9:27 AM Aleksandra Fedorova <afedor...@mirantis.com> wrote: > Hi, Vitaly, > > there is nothing to prevent us from triggering test based on event in > one project but checking out the code from another. > > So you can setup job triggered for patchset-created event in commit to > fuel-web/ repo. Then in this job you checkout both: code from fuel-web > and code from python-fuelclient in different subfolders, then run a > test, get result and vote on patchset to fuel-web repository. > > python-fuelclient failures are not new indeed, and we have a bug [1] > for 8.0 milestone to implement this kind of job. It will be much > easier for CI team if we get initial implementation of the test so we > can build a job on top. If you have some spare cycles - please > participate, feel free to send a patch to jenkins-jobs repository > directly [2] or comment on bug. > > [1] https://bugs.launchpad.net/fuel/+bug/1466897 > [2] https://review.fuel-infra.org/#/admin/projects/fuel-infra/jenkins-jobs > > On Wed, Oct 21, 2015 at 4:08 PM, Vitaly Kramskikh > <vkramsk...@mirantis.com> wrote: > > Hi, > > > > It's yet another time we broke fuelclient by merging a change in fuel-web > > repo. Since we are considering moving Fuel UI to a separate repo, and we > > need to run UI functional tests against changes in nailgun anyway, I > think > > we should start to change our CI so it could run tests from another repo > > against changes in another repo. > > > > Can it be done? > > > > -- > > Vitaly Kramskikh, > > Fuel UI Tech Lead, > > Mirantis, Inc. > > > > > __ > > OpenStack Development 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 > > > > > -- > Aleksandra Fedorova > Fuel CI Engineer > bookwar > > ______ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins
We should fix it everyone. I don't think we need to be too heavy with the
process, so I'd just update a single bug vs creating so many bugs...
Fuel Infra team - please provide an estimate when script is going to be
ready (which adds people automatically to gerrit review).
Thanks,
On Wed, Oct 21, 2015 at 6:04 AM Simon Pasquier <spasqu...@mirantis.com>
wrote:
> Mike, thanks for the clarification!
> I've filed a bug against fuel-qa [0] and submitted a patch [1]. Note that
> after a quick look, many Fuel projects have the same issue with the format
> of the MAINTAINERS file. Do you think we need one bug per project or do we
> piggy-back on the fuel-qa bug?
> BR,
> Simon
> [0] https://bugs.launchpad.net/fuel/+bug/1508449
> [1] https://review.openstack.org/#/c/238039/
>
> On Wed, Oct 21, 2015 at 8:11 AM, Mike Scherbakov <mscherba...@mirantis.com
> > wrote:
>
>> Nastya,
>> according to the template I provided initially [1] format in fuel-qa is
>> invalid. I've requested to support only one format [2].
>> File must always have a folder. If you want to cover the whole repo, then
>> the right structure would be
>>
>> maintainers:
>>
>>
>> - ./:
>>
>> - name: ...
>>
>> email: ...
>>
>> IRC:...
>> e.g. you'd just refer to the current folder, which should be root of the
>> repo by default.
>> Simon is asking a valid request: if you add his folder in the file, he
>> will be always added to the review request by script, once it's
>> implemented. Only in the case when contribution is made to his particular
>> area of responsibility.
>>
>> [1] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>> [2] https://bugs.launchpad.net/fuel/+bug/1497655
>>
>> On Tue, Oct 20, 2015 at 11:03 PM Anastasia Urlapova <
>> aurlap...@mirantis.com> wrote:
>>
>>> Simon,
>>> structure of fuel-web repo is much more complex than fuel-qa, ~ 50
>>> active contributors work with fuel-web.
>>> There is the functionality of the different Fuel domains and each
>>> requires its own expertise, so maintenance is divided by folders.
>>> In case of fuel-qa maintainers are doing review for whole repository,
>>> structure of file[0] is correct.
>>>
>>>
>>> Nastya.
>>> [0] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>>
>>> On Wed, Oct 21, 2015 at 2:15 AM, Mike Scherbakov <
>>> mscherba...@mirantis.com> wrote:
>>>
>>>> Simon,
>>>> I believe that it's a mistake in fuel-qa. Valid structure is in
>>>> fuel-web. Please fix the one in fuel-qa.
>>>>
>>>> I'm also looking forward for automated adding of people to review
>>>> requests based on this file. Here is the task to track it:
>>>> https://bugs.launchpad.net/fuel/+bug/1497655
>>>>
>>>> On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier <spasqu...@mirantis.com>
>>>> wrote:
>>>>
>>>>> Thanks for the reply, Andrew! I must admit that I haven't read
>>>>> thoroughly the specification on the new team structure [1]. IIUC plugin
>>>>> developers should be added to the MAINTAINERS file of fuel-qa for the
>>>>> directories that concern their plugins. If I take LMA as an example, this
>>>>> would be:
>>>>> fuelweb_test/tests/plugins/plugin_elasticsearch
>>>>> fuelweb_test/tests/plugins/plugin_lma_collector
>>>>> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>>>>>
>>>>> Is that right?
>>>>>
>>>>> I can submit a change to fuel-qa for adding the LMA team to the
>>>>> MAINTAINERS file but I can't figure out the structure of the YAML data:
>>>>> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
>>>>> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
>>>>> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>>>>>
>>>>> BR,
>>>>> Simon
>>>>>
>>>>> [1]
>>>>> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
>>>>> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>>>>> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>>>>
>>>>>
>>>>> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward <xar...@gmail.com>
>>>>> wrote:
>>
Re: [openstack-dev] [Fuel][Plugins] Plugin deployment questions
Hi all, is there a plan to remove this restriction permanently? Any bug/blueprint covering it? On Tue, Oct 20, 2015 at 5:07 AM Patrick Petit <ppe...@mirantis.com> wrote: > Hi Matthew, > > That’s useful. > Thanks > > On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) > wrote: > > Hi Patrick, > > During the 7.0 development cycle we made a lot of enhancements to what > environment characteristics can be modified through a plugin. One item that > plugins cannot directly modify is the default Fuel roles and their > metadata. That having been said, there is an open-ended post_install.sh > script you can use for your plugin to "hack" this value. I know of one > project that currently disables the requirement for controller role in a > deployment. This may be helpful in testing a given standalone role that > doesn't depend on a controller. > > Here's a link to the script: http://paste.openstack.org/show/476821/ > Note that this doesn't reflect "enabled" status of a plugin. It will make > controller min count 0 for all environments. That won't break them, but it > just removes the restriction. > > Best Regards, > Matthew Mosesohn > > On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> Hello folks, >> >> I second Patrick's idea. In our case we would like to install standalone >> RabbitMQ cluster with Fuel reference architecture to perform destructive >> tests on it. Requirement to install controller is an excessive burden in >> that case. >> >> Thanks, >> >> Dmitry >> >> 2015-10-19 13:44 GMT+03:00 Patrick Petit <ppe...@mirantis.com>: >> >>> Hi There, >>> >>> There are situations where we’d like to deploy only Fuel plugins in an >>> environment. >>> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA >>> tools. >>> Currently it’s not possible because you need to at least have one >>> controller. >>> What exactly is making that limitation? How hard would it be to have it >>> removed? >>> >>> Thanks >>> Patrick >>> >>> >>> __ >>> OpenStack Development 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 >>> >>> >> >> __ >> OpenStack Development 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 >> >> > __ > OpenStack Development 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 > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Modularization activity POC
Thanks Eugene. I'd recommend to start integration as early as possible... On Tue, Oct 20, 2015 at 2:11 AM Evgeniy L <e...@mirantis.com> wrote: > Hi Mike, > > 1. our plan is to have working partitioning/provisioning in a couple of > weeks, > networking is more complicated and it's better to ask Vladimir/Ryan. > 2, 3. here we have just some general ideas, we should have independent > releases on pypi, > each component should have responsible person (team), the same way we > do it for fuel-plugin-builder > and fuelclient. The same applies to independent docker containers. > Another thing is how > we are going to combine it in ready to use tool, there are several > ways, if we drop containers, > those will be just rpm/deb packages and dependencies between them, if > we continue using > docker containers, the simplest and the most robust way is to build a > single container which > has everything user needs. > > Regarding the spec our plan is to start writing spec after we have working > POC. > > Thanks, > > > On Tue, Oct 20, 2015 at 4:43 AM, Mike Scherbakov <mscherba...@mirantis.com > > wrote: > >> This is great start, Evgeny. >> I have a few questions: >> >>1. When do you expect to have POC to show? >>2. Do you plan to put new services into separate repos? >>3. How do you plan to package those - will you create RPM package for >>each, as well as Docker container (as we have everything in containers on >>Fuel master node) >> >> These questions, of course, should be covered in spec - so may be I >> should just wait for you guys to create specs. I just think that it's very >> important to think about integration from the very beginning. >> >> Thanks, >> >> On Mon, Oct 19, 2015 at 8:54 AM Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >> >>> Hey Evgeniy. >>> >>> This is awesome news1 I believe that microservices is way to go. >>> Despite the fact that them bring a set of classical problems (e.g. >>> duplication of domain entities) we will win more than loose. :) >>> >>> If there will be any specs or design meetings, please send me invite - >>> I'd gladly join discussions. >>> >>> Thanks, >>> Igor >>> >>> >>> >>> >>> On Wed, Oct 14, 2015 at 5:30 PM, Evgeniy L <e...@mirantis.com> wrote: >>> > Hi, >>> > >>> > We are starting Fuel modularization POC activity which is basically in >>> one >>> > sentence >>> > can be explained as "Use Fuel without Fuel", it means that we want to >>> > provide >>> > for a user a way to use some good things from Fuel, without entire >>> master >>> > node and >>> > other parts which user doesn't need. >>> > >>> > Currently we have monolithic system which includes every aspect of >>> > deployment >>> > logic, those components tightly coupled together, and there are few >>> persons >>> > who understand all the interactions between components. >>> > >>> > As a result of modularization we will get the next benefits: >>> > 1. reusability of components >>> > 1.1. it will lead to more components consumers (users) >>> > 1.2. better integration with the community (some community projects >>> might >>> >be interested in using some parts of Fuel) >>> > 2. components decoupling will lead to clear interfaces between >>> components >>> > 2.1. so it will be easier to replace some component >>> > 2.2. it will be easier to split the work between teams and it will help >>> > scale teams in >>> >a much more efficient way >>> > >>> > Here are some thing which naturally can be used separately: >>> > * network configuration (is a part of POC) >>> > * advanced partitioning/provisioning (is a part of POC) >>> > * discovery mechanism (ironic-inspector?) >>> > * power management (ironic?) >>> > * network verification >>> > * diagnostic snapshot >>> > * etc >>> > >>> > The main purpose of POC is to try to make partly working system to >>> figure >>> > out the >>> > scope of work which we will have to do upstream in order to make it >>> > production ready. >>> > >>> > Here are few basic component-specific ideas: >>> > >>> >
Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins
Nastya,
according to the template I provided initially [1] format in fuel-qa is
invalid. I've requested to support only one format [2].
File must always have a folder. If you want to cover the whole repo, then
the right structure would be
maintainers:
- ./:
- name: ...
email: ...
IRC:...
e.g. you'd just refer to the current folder, which should be root of the
repo by default.
Simon is asking a valid request: if you add his folder in the file, he will
be always added to the review request by script, once it's implemented.
Only in the case when contribution is made to his particular area of
responsibility.
[1] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
[2] https://bugs.launchpad.net/fuel/+bug/1497655
On Tue, Oct 20, 2015 at 11:03 PM Anastasia Urlapova <aurlap...@mirantis.com>
wrote:
> Simon,
> structure of fuel-web repo is much more complex than fuel-qa, ~ 50 active
> contributors work with fuel-web.
> There is the functionality of the different Fuel domains and each requires
> its own expertise, so maintenance is divided by folders.
> In case of fuel-qa maintainers are doing review for whole repository,
> structure of file[0] is correct.
>
>
> Nastya.
> [0] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>
> On Wed, Oct 21, 2015 at 2:15 AM, Mike Scherbakov <mscherba...@mirantis.com
> > wrote:
>
>> Simon,
>> I believe that it's a mistake in fuel-qa. Valid structure is in fuel-web.
>> Please fix the one in fuel-qa.
>>
>> I'm also looking forward for automated adding of people to review
>> requests based on this file. Here is the task to track it:
>> https://bugs.launchpad.net/fuel/+bug/1497655
>>
>> On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier <spasqu...@mirantis.com>
>> wrote:
>>
>>> Thanks for the reply, Andrew! I must admit that I haven't read
>>> thoroughly the specification on the new team structure [1]. IIUC plugin
>>> developers should be added to the MAINTAINERS file of fuel-qa for the
>>> directories that concern their plugins. If I take LMA as an example, this
>>> would be:
>>> fuelweb_test/tests/plugins/plugin_elasticsearch
>>> fuelweb_test/tests/plugins/plugin_lma_collector
>>> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>>>
>>> Is that right?
>>>
>>> I can submit a change to fuel-qa for adding the LMA team to the
>>> MAINTAINERS file but I can't figure out the structure of the YAML data:
>>> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
>>> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
>>> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>>>
>>> BR,
>>> Simon
>>>
>>> [1]
>>> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
>>> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
>>> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>>>
>>>
>>> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward <xar...@gmail.com>
>>> wrote:
>>>
>>>> We have already discussed this to be a result of describing data driven
>>>> testing, untill this spec is completed there is little sense to remove all
>>>> of these since fuel-qa is 100% required to operate this way. In the interim
>>>> we should just specify the appropriate SME with the MAINTAINERS file.
>>>>
>>>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
>>>> sgolovat...@mirantis.com> wrote:
>>>>
>>>>> Tests should be in plugin
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Sergii Golovatiuk,
>>>>> Skype #golserge
>>>>> IRC #holser
>>>>>
>>>>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <
>>>>> spasqu...@mirantis.com> wrote:
>>>>>
>>>>>> Hello Alexey,
>>>>>>
>>>>>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <aela...@mirantis.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Simon!
>>>>>>>
>>>>>>> We are going to remove plugins' functional tests from fuel-qa
>>>>>>> because this tests don't use for our plugins CI process.
>>>>>>>
>>>>>>
>>>>>> And where are the existing tests going to be stored then?
>>>>>>
>>>>>> Thanks,
>
Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins
Simon,
I believe that it's a mistake in fuel-qa. Valid structure is in fuel-web.
Please fix the one in fuel-qa.
I'm also looking forward for automated adding of people to review requests
based on this file. Here is the task to track it:
https://bugs.launchpad.net/fuel/+bug/1497655
On Tue, Oct 20, 2015 at 2:10 AM Simon Pasquier <spasqu...@mirantis.com>
wrote:
> Thanks for the reply, Andrew! I must admit that I haven't read thoroughly
> the specification on the new team structure [1]. IIUC plugin developers
> should be added to the MAINTAINERS file of fuel-qa for the directories that
> concern their plugins. If I take LMA as an example, this would be:
> fuelweb_test/tests/plugins/plugin_elasticsearch
> fuelweb_test/tests/plugins/plugin_lma_collector
> fuelweb_test/tests/plugins/plugin_lma_infra_alerting
>
> Is that right?
>
> I can submit a change to fuel-qa for adding the LMA team to the
> MAINTAINERS file but I can't figure out the structure of the YAML data:
> fuel-web/MAINTAINERS [2] is organized as "{directory1: [maintainer1,
> maintainer2, ...], directory2: [...], ...}" while for fuel-qa [3] (and
> other Fuel projects), it's "[maintainer1, maintainer2, ...]".
>
> BR,
> Simon
>
> [1]
> http://specs.fuel-infra.org/fuel-specs-master/policy/team-structure.html
> [2] https://github.com/openstack/fuel-web/blob/master/MAINTAINERS
> [3] https://github.com/openstack/fuel-qa/blob/master/MAINTAINERS
>
>
> On Sat, Oct 17, 2015 at 2:21 AM, Andrew Woodward <xar...@gmail.com> wrote:
>
>> We have already discussed this to be a result of describing data driven
>> testing, untill this spec is completed there is little sense to remove all
>> of these since fuel-qa is 100% required to operate this way. In the interim
>> we should just specify the appropriate SME with the MAINTAINERS file.
>>
>> On Fri, Oct 16, 2015 at 11:34 AM Sergii Golovatiuk <
>> sgolovat...@mirantis.com> wrote:
>>
>>> Tests should be in plugin
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Fri, Oct 16, 2015 at 5:58 PM, Simon Pasquier <spasqu...@mirantis.com>
>>> wrote:
>>>
>>>> Hello Alexey,
>>>>
>>>> On Fri, Oct 16, 2015 at 5:35 PM, Alexey Elagin <aela...@mirantis.com>
>>>> wrote:
>>>>
>>>>> Hello Simon!
>>>>>
>>>>> We are going to remove plugins' functional tests from fuel-qa because
>>>>> this tests don't use for our plugins CI process.
>>>>>
>>>>
>>>> And where are the existing tests going to be stored then?
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>>
>>>>>
>>>>>
>>>>> __
>>>>> OpenStack Development 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
>>>>>
>>>>
>>>>
>>>>
>>>> __
>>>> OpenStack Development 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
>>>>
>>>>
>>>
>>> __
>>> OpenStack Development 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
>>>
>> --
>>
>> --
>>
>> Andrew Woodward
>>
>> Mirantis
>>
>> Fuel Community Ambassador
>>
>> Ceph Community
>>
>> __
>> OpenStack Development 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
>>
>>
> __
> OpenStack Development 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
>
--
Mike Scherbakov
#mihgen
__
OpenStack Development 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
Re: [openstack-dev] [Fuel][Fuel-Modularization] Proposal on Decoupling Serializers from Nailgun
e inheritance, polymorphism and > incapsulation pretty much in OOP mode but with ability for deployment > engineers to apply versioning to serializers and allow each particular task > to work with different sources of data with different versions of API. > > What this actually means: each task has a step called 'translation' which > fetches attributes from any arbitrary set of sources and converts them into > the format that is consumable by the deployment stage of this task. From > our current architectural point of view it will look like generation of a > set of yaml files that will be merged by hiera so that each puppet task can > leverage the power of hiera. > > This actually means that in scope of our modularization initiative each > module should have an API which will be accessed by those tasks in runtime > right before the tasks are executed. This also means that if a user changes > some of the values in the databases of those modules, rerun of such task > will lead to a different result of 'translation' and trigger some actions > like 'keystone_config ~> Service[keystone]' in puppet. > > There is a tough discussion (etherpad here:[4]) on: > > 1) how to handle versioning/revert capabilities > 2) where to store output produced by those 'translators' > 3) which type of the storage to use > > Please, feel free to provide your feedback on this approach and tell me > where this approach is going to be wrong. > > [0] http://permalink.gmane.org/gmane.comp.cloud.openstack.devel/66563 > [1] > https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/deployment_serializers.py > [2] > https://github.com/stackforge/fuel-web/blob/master/nailgun/nailgun/orchestrator/provisioning_serializers.py > [3] https://github.com/xenolog/l23network > [4] https://etherpad.openstack.org/p/data-processor-per-component > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru > vkuk...@mirantis.com > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] PTL & Component Leads elections
Congrats Igor! Sergey - thanks for help. On Mon, Oct 19, 2015 at 2:48 AM Sergey Lukjanov <slukja...@mirantis.com> wrote: > Hi folks, > > it's time to start voting for the component leads. > > There was only one candidate for the Fuel Python Component Lead, so, no > need for voting. Congrats to Igor Kalnitsky! > > For the Fuel Library Component Lead we have two candidates and you should > receive an email with title "Poll: Fuel Library Component Lead Elections > Fall 2015" soon to vote for them. Please, don't share / forward this email, > it contains your personal unique token for the voting. > > The estimated date for the voting end is Oct 22. > > Thanks. > > On Tue, Oct 13, 2015 at 4:05 PM, Tomasz Napierala <tnapier...@mirantis.com > > wrote: > >> Congrats Dmitry! Well deserved. >> >> >> > On 09 Oct 2015, at 19:13, Mike Scherbakov <mscherba...@mirantis.com> >> wrote: >> > >> > Congratulations to Dmitry! >> > Now you are officially titled with PTL. >> > It won't be easy, but we will support you! >> > >> > 118 contributors voted. Thanks everyone! Thank you Sergey for >> organizing elections for us. >> > >> > On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov <slukja...@mirantis.com> >> wrote: >> > Voting period ended and so we have an officially selected Fuel PTL - >> DB. Congrats! >> > >> > Poll results & details - >> http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0 >> > >> > Let's start proposing candidates for the component lead positions! >> > >> > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov < >> slukja...@mirantis.com> wrote: >> > Hi folks, >> > >> > I've just setup the voting system and you should start receiving email >> with topic "Poll: Fuel PTL Elections Fall 2015". >> > >> > NOTE: Please, don't forward this email, it contains *personal* unique >> token for the voting. >> > >> > Thanks. >> > >> > On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com> >> wrote: >> > +1 to Igor. Do we have voting system set up? >> > >> > On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky < >> ikalnit...@mirantis.com> wrote: >> > > * September 29 - October 8: PTL elections >> > >> > So, it's in progress. Where I can vote? I didn't receive any emails. >> > >> > On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala >> > <tnapier...@mirantis.com> wrote: >> > >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com> >> wrote: >> > >> >> > >> >> > >> Time line: >> > >> >> > >> PTL elections >> > >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL >> position >> > >> * September 29 - October 8: PTL elections >> > > >> > > Just a reminder that we have a deadline for candidates today. >> > > >> > > Regards, >> > > -- >> > > Tomasz 'Zen' Napierala >> > > Product Engineering - Poland >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> __ >> > > OpenStack Development 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 >> > >> > >> __ >> > OpenStack Development 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 >> > >> > >> > >> > -- >> > Yours Faithfully, >> > Vladimir Kuklin, >> > Fuel Library Tech Lead, >> > Mirantis, Inc. >> > +7 (495) 640-49-04 >> > +7 (926) 702-39-68 >> > Skype kuklinvv >> > 35bk3, Vorontsovskaya Str. >> > Moscow, Russia, >> > www.mirantis.com >> > www.mirantis.ru >> > vkuk...@mirantis.com >> > >> > >> __ >> > Open
Re: [openstack-dev] [Fuel] Modularization activity POC
gt; extendability, > > currently we have a problem that all of the logic which is related to > > deployment > > data is hardcoded in Nailgun. Plugins should be able to retrieve any > data it > > needs from the system, in order to perform plugin deployment, these data > > should > > be retrieved using some interface, and we already have interface where we > > can > > provide stability and versioning, it's REST API. So basically deployment > > should > > consist of two steps first is to retrieve all required data from any > source > > it needs, > > and after that send data to the nodes and start deployment. > > > > If you have any questions/suggestion don't hesitate to ask. > > > > Thanks, > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] deployment tests for fuel-library switched to Liberty-based ISO
We just discussed it during the lunch with D.Borodaenko :) Thanks a lot! On Fri, Oct 16, 2015 at 12:48 PM Aleksandra Fedorova <afedor...@mirantis.com> wrote: > Hi, everyone, please be informed, > > Liberty-based Fuel ISO image now passes Build Verification Test [1]. > > Therefore both deployment tests [2] and [3] for fuel-library > repository are now switched from Kilo to Liberty-based ISO. > > > Latest nightly build for 8.0 ISO with Liberty OpenStack is available > at https://ci.fuel-infra.org/. > > > [1] https://ci.fuel-infra.org/job/8.0.fuel_community.ubuntu.bvt_2/16/ > [2] > https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.neutron_vlan_ha/ > [3] https://ci.fuel-infra.org/job/fuellib_review_pkgs_master_node/ > > -- > Aleksandra Fedorova > Fuel CI Engineer > bookwar > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Product] [fuel] Life cycle management use cases
Hi Shamail, thank you for letting me know. I didn't come through the page when I was googling. We are collecting use cases though for underlay, so it's more relevant for such projects as Fuel, TripleO, Puppet OpenStack; than for VM, DB, etc. related management. If you have any work started on underlay, I'll be more than happy to collaborate. PS. Meanwhile we've got lots of feedback in the etherpad, thanks all! On Wed, Oct 14, 2015 at 3:34 PM Shamail <itzsham...@gmail.com> wrote: > Great topic... > > Please note that the Product WG[1] also has a user story focused on > Lifecycle Management. While FUEL is one aspect of the overall workflow, we > would also like the team to consider project level enhancements (e.g. > garbage collection inside the DB). > > The Product WG would welcome your insights on lifecycle management > tremendously. Please help by posting comments to our existing user > story[2]. > > > [1] https://wiki.openstack.org/wiki/ProductTeam > [2] > http://specs.openstack.org/openstack/openstack-user-stories/user-stories/draft/lifecycle_management.html > > Thanks, > Shamail > > > On Oct 14, 2015, at 5:04 PM, Mike Scherbakov <mscherba...@mirantis.com> > wrote: > > > > Hi fuelers, > > as we all know, Fuel lacks many of life cycle management (LCM) use > cases. It becomes a very hot issue for many of our users, as current LCM > capabilities are not very rich. > > > > In order to think how we can fix it, we need to collect use cases first, > and prioritize them if needed. So that whatever a change in architecture we > are about to make, we would need to ensure that we meet LCM use cases or > have a proposal how to close it in a foreseeable future. > > > > I started to collect use cases in the etherpad: > https://etherpad.openstack.org/p/lcm-use-cases. > > > > Please contribute in there. > > > > Thank you, > > -- > > Mike Scherbakov > > #mihgen > > > __ > > OpenStack Development 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 > ___ > Product-wg mailing list > product...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [fuel] Life cycle management use cases
Hi fuelers, as we all know, Fuel lacks many of life cycle management (LCM) use cases. It becomes a very hot issue for many of our users, as current LCM capabilities are not very rich. In order to think how we can fix it, we need to collect use cases first, and prioritize them if needed. So that whatever a change in architecture we are about to make, we would need to ensure that we meet LCM use cases or have a proposal how to close it in a foreseeable future. I started to collect use cases in the etherpad: https://etherpad.openstack.org/p/lcm-use-cases. Please contribute in there. Thank you, -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Changes in bugs workflow on Launchpad
Dmitry, I think that #1 is reasonable. For #2, separate LP projects, I'd want to assess pros/cons before making a decision. I see more cons at the moment. I've started adding it in the etherpad, I'd appreciate if other folks would join and provide their input there. Thank you, On Tue, Oct 13, 2015 at 11:34 AM Dmitry Pyzhov <dpyz...@mirantis.com> wrote: > Guys, > > I propose several changes in bugs workflow on Launchpad. > 1) Let's stop using component based team groups as assignees for bugs > 2) Let's create separate Launchpad projects for qa, docs and infra teams > > It will affect everyone who tracks any list of bugs. So I want to be sure > that everyone can ask question or raise concern. > > Why do we need this? We are growing community. In 7.0 release we addressed > 2153 bugs. This number is almost unmanageable. We have a lot of tags (99 > official and 219 other tags), a lot of Launchpad groups. We have several > big teams with their own workflows. We have 1482 bugs in our current > release. In order to understand if a bug in really a bug or some kind of > support request one have to analyse its tags, assignee and teams of > assignee. And there is a chance that the analysis will produce wrong result. > > I'm trying to make our bug management as clear as possible and produce as > little extra everyday mouse clicking as possible. Here is list of required > changes: https://etherpad.openstack.org/p/fuel-bugs-taxonomy > > Feel free to ask questions. > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] PTL & Component Leads elections
Congratulations to Dmitry! Now you are officially titled with PTL. It won't be easy, but we will support you! 118 contributors voted. Thanks everyone! Thank you Sergey for organizing elections for us. On Thu, Oct 8, 2015 at 3:52 PM Sergey Lukjanov <slukja...@mirantis.com> wrote: > Voting period ended and so we have an officially selected Fuel PTL - DB. > Congrats! > > Poll results & details - > http://civs.cs.cornell.edu/cgi-bin/results.pl?num_winners=1=E_b79041aa56684ec0 > > Let's start proposing candidates for the component lead positions! > > On Wed, Sep 30, 2015 at 8:47 PM, Sergey Lukjanov <slukja...@mirantis.com> > wrote: > >> Hi folks, >> >> I've just setup the voting system and you should start receiving email >> with topic "Poll: Fuel PTL Elections Fall 2015". >> >> NOTE: Please, don't forward this email, it contains *personal* unique >> token for the voting. >> >> Thanks. >> >> On Wed, Sep 30, 2015 at 3:28 AM, Vladimir Kuklin <vkuk...@mirantis.com> >> wrote: >> >>> +1 to Igor. Do we have voting system set up? >>> >>> On Wed, Sep 30, 2015 at 4:35 AM, Igor Kalnitsky <ikalnit...@mirantis.com >>> > wrote: >>> >>>> > * September 29 - October 8: PTL elections >>>> >>>> So, it's in progress. Where I can vote? I didn't receive any emails. >>>> >>>> On Mon, Sep 28, 2015 at 7:31 PM, Tomasz Napierala >>>> <tnapier...@mirantis.com> wrote: >>>> >> On 18 Sep 2015, at 04:39, Sergey Lukjanov <slukja...@mirantis.com> >>>> wrote: >>>> >> >>>> >> >>>> >> Time line: >>>> >> >>>> >> PTL elections >>>> >> * September 18 - September 28, 21:59 UTC: Open candidacy for PTL >>>> position >>>> >> * September 29 - October 8: PTL elections >>>> > >>>> > Just a reminder that we have a deadline for candidates today. >>>> > >>>> > Regards, >>>> > -- >>>> > Tomasz 'Zen' Napierala >>>> > Product Engineering - Poland >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> __ >>>> > OpenStack Development 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 >>>> >>>> >>>> __ >>>> OpenStack Development 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 >>>> >>> >>> >>> >>> -- >>> Yours Faithfully, >>> Vladimir Kuklin, >>> Fuel Library Tech Lead, >>> Mirantis, Inc. >>> +7 (495) 640-49-04 >>> +7 (926) 702-39-68 >>> Skype kuklinvv >>> 35bk3, Vorontsovskaya Str. >>> Moscow, Russia, >>> www.mirantis.com <http://www.mirantis.ru/> >>> www.mirantis.ru >>> vkuk...@mirantis.com >>> >>> >>> __ >>> OpenStack Development 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 >>> >>> >> >> >> -- >> Sincerely yours, >> Sergey Lukjanov >> Sahara Technical Lead >> (OpenStack Data Processing) >> Principal Software Engineer >> Mirantis Inc. >> > > > > -- > Sincerely yours, > Sergey Lukjanov > Sahara Technical Lead > (OpenStack Data Processing) > Principal Software Engineer > Mirantis Inc. > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Core Reviewers groups restructure
Update here: patch was marked as WIP for now due to comment from Anita Kuno: > On Oct. 17 all active stackforge projects that have themselves listed on the stackforge retirement wikipage will be moved. This includes reviewing all acl files for that move. > Can we mark this patch wip until after the Oct. 17 stackforge rename and then change the paths on these files to the openstack namespace? On Thu, Oct 1, 2015 at 4:03 PM Dmitry Borodaenko <dborodae...@mirantis.com> wrote: > This commit brings Fuel ACLs in sync with each other and in line with > the agreement on this thread: > https://review.openstack.org/230195 > > Please review carefully. Note that I intentionally didn't touch any of > the plugins ACLs, primarily to save time for us and the > openstack-infra team until after the stackforge->openstack namespace > migration. > > On Mon, Sep 21, 2015 at 4:17 PM, Mike Scherbakov > <mscherba...@mirantis.com> wrote: > > Thanks guys. > > So for fuel-octane then there are no actions needed. > > > > For fuel-agent-core group [1], looks like we are already good (it doesn't > > have fuel-core group nested). But it would need to include fuel-infra > group > > and remove Aleksandra Fedorova (she will be a part of fuel-infra group). > > > > python-fuel-client-core [2] is good as well (no nested fuel-core). > However, > > there is another group python-fuelclient-release [3], which has to be > > eliminated, and main python-fuelclient-core would just have fuel-infra > group > > included for maintenance purposes. > > > > [1] https://review.openstack.org/#/admin/groups/995,members > > [2] https://review.openstack.org/#/admin/groups/551,members > > [3] https://review.openstack.org/#/admin/groups/552,members > > > > > > On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh <ogelb...@mirantis.com> > wrote: > >> > >> FYI, we have a separate core group for stackforge/fuel-octane repository > >> [1]. > >> > >> I'm supporting the move to modularization of Fuel with cleaner > separation > >> of authority and better defined interfaces. Thus, I'm +1 to such a > change as > >> a part of that move. > >> > >> [1] https://review.openstack.org/#/admin/groups/1020,members > >> > >> -- > >> Best regards, > >> Oleg Gelbukh > >> > >> On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov > >> <mscherba...@mirantis.com> wrote: > >>> > >>> Hi all, > >>> as of my larger proposal on improvements to code review workflow [1], > we > >>> need to have cores for repositories, not for the whole Fuel. It is the > path > >>> we are taking for a while, and new core reviewers added to specific > repos > >>> only. Now we need to complete this work. > >>> > >>> My proposal is: > >>> > >>> Get rid of one common fuel-core [2] group, members of which can merge > >>> code anywhere in Fuel. Some members of this group may cover a couple of > >>> repositories, but can't really be cores in all repos. > >>> Extend existing groups, such as fuel-library [3], with members from > >>> fuel-core who are keeping up with large number of reviews / merges. > This > >>> data can be queried at Stackalytics. > >>> Establish a new group "fuel-infra", and ensure that it's included into > >>> any other core group. This is for maintenance purposes, it is expected > to be > >>> used only in exceptional cases. Fuel Infra team will have to decide > whom to > >>> include into this group. > >>> Ensure that fuel-plugin-* repos will not be affected by removal of > >>> fuel-core group. > >>> > >>> #2 needs specific details. Stackalytics can show active cores easily, > we > >>> can look at people with *: > >>> http://stackalytics.com/report/contribution/fuel-web/180. This is for > >>> fuel-web, change the link for other repos accordingly. If people are > added > >>> specifically to the particular group, leaving as is (some of them are > no > >>> longer active. But let's clean them up separately from this group > >>> restructure process). > >>> > >>> fuel-library-core [3] group will have following members: Bogdan D., > >>> Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko. > >>> fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, > Vitaly > >>> Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak > >>
Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session
Looks like we need to make it totally clear in our policy... > So we assume that detailed architectural work will be relayed to Component Leads I don't agree with this statement, as it implies that _all_ architectural work will be relayed to component leads. PTL is fully responsible for technical direction of the project. However, since the project is large, I'd expect that PTL will rely on Component Leads for most of particular technical decisions to be made. At the same time, PTL defines technical direction for the project, and ensures that component leads as well as others are aligned to it. If people are not aligned, it's job of PTL in the first order to: a) delegate alignment work to Component Lead if possible b) make yourself available to participate in alignment and resolving disputes, if component leads can't do it or if there is misalignment between Component Leads or Component Leads and PTL or Component Leads and PTLs of other OpenStack projects. I hope that this definition most of fuelers will find reasonable... but as I said, we need to spend some time and get it crystal clear in our policy. On Tue, Oct 6, 2015 at 8:45 AM Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Which is actually contradictory and ambiguous and shows that PTL has less > power than CLs while CLs at the same time have less power than PTL. I think > this is the time when universe should collapse as we found that time-space > is contradicting laws of propositional calculus. > > On Tue, Oct 6, 2015 at 6:26 PM, Tomasz Napierala <tnapier...@mirantis.com> > wrote: > >> Hi >> >> That’s right, but we made slight change here: >> "Define architecture direction & review majority of design specs. Rely on >> Component Leads and Core Reviewers" >> >> So we assume that detailed architectural work will be relayed to >> Component Leads >> >> >> > On 02 Oct 2015, at 10:12, Evgeniy L <e...@mirantis.com> wrote: >> > >> > Hi Mike, >> > >> > According to the description of the role, I wouldn't say that the role >> is less architectural than >> > political, since PTL should review designs and resolve conflicts >> between cores (which are >> > usually technical), PTL should also have strong skills in software >> architecture, and understanding >> > of what Fuel should look like. >> > >> > Thanks, >> > >> > On Thu, Oct 1, 2015 at 11:32 PM, Mike Scherbakov < >> mscherba...@mirantis.com> wrote: >> > > we may mix technical direction / tech debt roadmap and process, >> political, and people management work of PTL. >> > sorry, of course I meant that we rather should NOT mix these things. >> > >> > To make my email very short, I'd say PTL role is more political and >> process-wise rather than architectural. >> > >> > On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov < >> mscherba...@mirantis.com> wrote: >> > Vladimir, >> > we may mix technical direction / tech debt roadmap and process, >> political, and people management work of PTL. >> > >> > PTL definition in OpenStack [1] reflects many things which PTL becomes >> responsible for. This applies to Fuel as well. >> > >> > I'd like to reflect some things here which I'd expect PTL doing, most >> of which will intersect with [1]: >> > - Participate in cross-project initiatives & resolution of issues >> around it. Great example is puppet-openstack vs Fuel [2] >> > - Organize required processes around launchpad bugs & blueprints >> > - Personal personal feedback to Fuel contributors & public suggestions >> when needed >> > - Define architecture direction & review majority of design specs. Rely >> on Component Leads and Core Reviewers >> > - Ensure that roadmap & use cases are aligned with architecture work >> > - Resolve conflicts between core reviewers, component leads. Get people >> to the same page >> > - Watch for code review queues and quality of reviews. Ensure >> discipline of code review. >> > - Testing / coverage have to be at the high level >> > >> > Considering all above, contributors actually have been working with all >> of us and know who could be better handling such a hard work. I don't think >> special Q is needed. If there are concerns / particular process/tech >> questions we'd like to discuss - those should be just open as email threads. >> > >> > [1] https://wiki.openstack.org/wiki/PTL_Guide >> > [2] >> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html >> > &g
Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session
> we may mix technical direction / tech debt roadmap and process, political, and people management work of PTL. sorry, of course I meant that we rather should NOT mix these things. To make my email very short, I'd say PTL role is more political and process-wise rather than architectural. On Wed, Sep 30, 2015 at 5:48 PM Mike Scherbakov <mscherba...@mirantis.com> wrote: > Vladimir, > we may mix technical direction / tech debt roadmap and process, political, > and people management work of PTL. > > PTL definition in OpenStack [1] reflects many things which PTL becomes > responsible for. This applies to Fuel as well. > > I'd like to reflect some things here which I'd expect PTL doing, most of > which will intersect with [1]: > - Participate in cross-project initiatives & resolution of issues around > it. Great example is puppet-openstack vs Fuel [2] > - Organize required processes around launchpad bugs & blueprints > - Personal personal feedback to Fuel contributors & public suggestions > when needed > - Define architecture direction & review majority of design specs. Rely on > Component Leads and Core Reviewers > - Ensure that roadmap & use cases are aligned with architecture work > - Resolve conflicts between core reviewers, component leads. Get people to > the same page > - Watch for code review queues and quality of reviews. Ensure discipline > of code review. > - Testing / coverage have to be at the high level > > Considering all above, contributors actually have been working with all of > us and know who could be better handling such a hard work. I don't think > special Q is needed. If there are concerns / particular process/tech > questions we'd like to discuss - those should be just open as email threads. > > [1] https://wiki.openstack.org/wiki/PTL_Guide > [2] > http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html > > Thank you, > > On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin <vkuk...@mirantis.com> > wrote: > >> Folks >> >> I think it is awesome we have three candidates for PTL position in Fuel. >> I read all candidates' emails (including mine own several times :-) ) and I >> got a slight thought of not being able to really differentiate the >> candidates platforms as they are almost identical from the high-level point >> of view. But we all know that the devil is in details. And this details >> will actually affect project future. >> >> Thus I thought about Q session at #fuel-dev channel in IRC. I think >> that this will be mutually benefitial for everyone to get our platforms a >> little bit more clear. >> >> Let's do it before or right at the start of actual voting so that our >> contributors can make better decisions based on this session. >> >> I suggest the following format: >> >> 1) 3 questions from electorate members - let's put them onto an etherpad >> 2) 2 questions from a candidate to his opponents (1 question per opponent) >> 3) external moderator - I suppose, @xarses as our weekly meeting >> moderator could help us >> 4) time and date - Wednesday or Thursday comfortable for both timezones, >> e.g. after 4PM UTC or right after fuel weekly meeting. >> >> What do you think, folks? >> >> -- >> Yours Faithfully, >> Vladimir Kuklin, >> Fuel Library Tech Lead, >> Mirantis, Inc. >> +7 (495) 640-49-04 >> +7 (926) 702-39-68 >> Skype kuklinvv >> 35bk3, Vorontsovskaya Str. >> Moscow, Russia, >> www.mirantis.com <http://www.mirantis.ru/> >> www.mirantis.ru >> vkuk...@mirantis.com >> __ >> OpenStack Development 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 >> > -- > Mike Scherbakov > #mihgen > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Remove nova-network as a deployment option in Fuel?
Hi team, where do we stand with it now? I remember there was a plan to remove nova-network support in 7.0, but we've delayed it due to vcenter/dvr or something which was not ready for it. Can we delete it now? The early in the cycle we do it, the easier it will be. Thanks! -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][PTL] PTL Candidates Q Session
Vladimir, we may mix technical direction / tech debt roadmap and process, political, and people management work of PTL. PTL definition in OpenStack [1] reflects many things which PTL becomes responsible for. This applies to Fuel as well. I'd like to reflect some things here which I'd expect PTL doing, most of which will intersect with [1]: - Participate in cross-project initiatives & resolution of issues around it. Great example is puppet-openstack vs Fuel [2] - Organize required processes around launchpad bugs & blueprints - Personal personal feedback to Fuel contributors & public suggestions when needed - Define architecture direction & review majority of design specs. Rely on Component Leads and Core Reviewers - Ensure that roadmap & use cases are aligned with architecture work - Resolve conflicts between core reviewers, component leads. Get people to the same page - Watch for code review queues and quality of reviews. Ensure discipline of code review. - Testing / coverage have to be at the high level Considering all above, contributors actually have been working with all of us and know who could be better handling such a hard work. I don't think special Q is needed. If there are concerns / particular process/tech questions we'd like to discuss - those should be just open as email threads. [1] https://wiki.openstack.org/wiki/PTL_Guide [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066685.html Thank you, On Tue, Sep 29, 2015 at 3:47 AM Vladimir Kuklin <vkuk...@mirantis.com> wrote: > Folks > > I think it is awesome we have three candidates for PTL position in Fuel. I > read all candidates' emails (including mine own several times :-) ) and I > got a slight thought of not being able to really differentiate the > candidates platforms as they are almost identical from the high-level point > of view. But we all know that the devil is in details. And this details > will actually affect project future. > > Thus I thought about Q session at #fuel-dev channel in IRC. I think that > this will be mutually benefitial for everyone to get our platforms a little > bit more clear. > > Let's do it before or right at the start of actual voting so that our > contributors can make better decisions based on this session. > > I suggest the following format: > > 1) 3 questions from electorate members - let's put them onto an etherpad > 2) 2 questions from a candidate to his opponents (1 question per opponent) > 3) external moderator - I suppose, @xarses as our weekly meeting moderator > could help us > 4) time and date - Wednesday or Thursday comfortable for both timezones, > e.g. after 4PM UTC or right after fuel weekly meeting. > > What do you think, folks? > > -- > Yours Faithfully, > Vladimir Kuklin, > Fuel Library Tech Lead, > Mirantis, Inc. > +7 (495) 640-49-04 > +7 (926) 702-39-68 > Skype kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com <http://www.mirantis.ru/> > www.mirantis.ru > vkuk...@mirantis.com > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Core Reviewers groups restructure
Thanks guys. So for fuel-octane then there are no actions needed. For fuel-agent-core group [1], looks like we are already good (it doesn't have fuel-core group nested). But it would need to include fuel-infra group and remove Aleksandra Fedorova (she will be a part of fuel-infra group). python-fuel-client-core [2] is good as well (no nested fuel-core). However, there is another group python-fuelclient-release [3], which has to be eliminated, and main python-fuelclient-core would just have fuel-infra group included for maintenance purposes. [1] https://review.openstack.org/#/admin/groups/995,members [2] https://review.openstack.org/#/admin/groups/551,members [3] https://review.openstack.org/#/admin/groups/552,members On Mon, Sep 21, 2015 at 11:06 AM Oleg Gelbukh <ogelb...@mirantis.com> wrote: > FYI, we have a separate core group for stackforge/fuel-octane repository > [1]. > > I'm supporting the move to modularization of Fuel with cleaner separation > of authority and better defined interfaces. Thus, I'm +1 to such a change > as a part of that move. > > [1] https://review.openstack.org/#/admin/groups/1020,members > > -- > Best regards, > Oleg Gelbukh > > On Sun, Sep 20, 2015 at 11:56 PM, Mike Scherbakov < > mscherba...@mirantis.com> wrote: > >> Hi all, >> as of my larger proposal on improvements to code review workflow [1], we >> need to have cores for repositories, not for the whole Fuel. It is the path >> we are taking for a while, and new core reviewers added to specific repos >> only. Now we need to complete this work. >> >> My proposal is: >> >>1. Get rid of one common fuel-core [2] group, members of which can >>merge code anywhere in Fuel. Some members of this group may cover a couple >>of repositories, but can't really be cores in all repos. >>2. Extend existing groups, such as fuel-library [3], with members >>from fuel-core who are keeping up with large number of reviews / merges. >>This data can be queried at Stackalytics. >>3. Establish a new group "fuel-infra", and ensure that it's included >>into any other core group. This is for maintenance purposes, it is >> expected >>to be used only in exceptional cases. Fuel Infra team will have to decide >>whom to include into this group. >>4. Ensure that fuel-plugin-* repos will not be affected by removal of >>fuel-core group. >> >> #2 needs specific details. Stackalytics can show active cores easily, we >> can look at people with *: >> http://stackalytics.com/report/contribution/fuel-web/180. This is for >> fuel-web, change the link for other repos accordingly. If people are added >> specifically to the particular group, leaving as is (some of them are no >> longer active. But let's clean them up separately from this group >> restructure process). >> >>- fuel-library-core [3] group will have following members: Bogdan D., >>Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko. >>- fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, >>Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak >>- fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li >>- fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K. >>- fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky, Nastya >>Urlapova >>- fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny >>Konstantinov, Olga Gusarenko >>- fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry >>Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky >>- fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov >>- fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey >>Sledzinsky, Dmitry Shulyak >>- fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin >>- fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya >>Urlapova >>- fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly >>Kramskikh >>- fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey >>Kasatkin (this project seems to be dead, let's consider to rip it off) >>- fuel-specs-core: there is no such a group at the moment. I propose >>to create one with following members, based on stackalytics data [16]: >>Vitaly Kramskikh, Bogdan Dobrelia, Evgeny Li, Sergii Golovatyuk, Vladimir >>Kuklin, Igor Kalnitsky, Alexey Kasatkin, Roman Vyalov, Dmitry Borodaenko, >>Mike Scherbakov, Dmitry Pyzhov. We would need to reconsider who can merge >>after Fuel PTL/Component Leads elections >>- fuel-octane
[openstack-dev] [Fuel] Core Reviewers groups restructure
Hi all, as of my larger proposal on improvements to code review workflow [1], we need to have cores for repositories, not for the whole Fuel. It is the path we are taking for a while, and new core reviewers added to specific repos only. Now we need to complete this work. My proposal is: 1. Get rid of one common fuel-core [2] group, members of which can merge code anywhere in Fuel. Some members of this group may cover a couple of repositories, but can't really be cores in all repos. 2. Extend existing groups, such as fuel-library [3], with members from fuel-core who are keeping up with large number of reviews / merges. This data can be queried at Stackalytics. 3. Establish a new group "fuel-infra", and ensure that it's included into any other core group. This is for maintenance purposes, it is expected to be used only in exceptional cases. Fuel Infra team will have to decide whom to include into this group. 4. Ensure that fuel-plugin-* repos will not be affected by removal of fuel-core group. #2 needs specific details. Stackalytics can show active cores easily, we can look at people with *: http://stackalytics.com/report/contribution/fuel-web/180. This is for fuel-web, change the link for other repos accordingly. If people are added specifically to the particular group, leaving as is (some of them are no longer active. But let's clean them up separately from this group restructure process). - fuel-library-core [3] group will have following members: Bogdan D., Sergii G., Alex Schultz, Vladimir Kuklin, Alex Didenko. - fuel-web-core [4]: Sebastian K., Igor Kalnitsky, Alexey Kasatkin, Vitaly Kramskikh, Julia Aranovich, Evgeny Li, Dima Shulyak - fuel-astute-core [5]: Vladimir Sharshov, Evgeny Li - fuel-dev-tools-core [6]: Przemek Kaminski, Sebastian K. - fuel-devops-core [7]: Tatyana Leontovich, Andrey Sledzinsky, Nastya Urlapova - fuel-docs-core [8]: Irina Povolotskaya, Denis Klepikov, Evgeny Konstantinov, Olga Gusarenko - fuel-main-core [9]: Vladimir Kozhukalov, Roman Vyalov, Dmitry Pyzhov, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky - fuel-nailgun-agent-core [10]: Vladimir Sharshov, V.Kozhukalov - fuel-ostf-core [11]: Tatyana Leontovich, Nastya Urlapova, Andrey Sledzinsky, Dmitry Shulyak - fuel-plugins-core [12]: Igor Kalnitsky, Evgeny Li, Alexey Kasatkin - fuel-qa-core [13]: Andrey Sledzinsky, Tatyana Leontovich, Nastya Urlapova - fuel-stats-core [14]: Alex Kislitsky, Alexey Kasatkin, Vitaly Kramskikh - fuel-tasklib-core [15]: Igor Kalnitsky, Dima Shulyak, Alexey Kasatkin (this project seems to be dead, let's consider to rip it off) - fuel-specs-core: there is no such a group at the moment. I propose to create one with following members, based on stackalytics data [16]: Vitaly Kramskikh, Bogdan Dobrelia, Evgeny Li, Sergii Golovatyuk, Vladimir Kuklin, Igor Kalnitsky, Alexey Kasatkin, Roman Vyalov, Dmitry Borodaenko, Mike Scherbakov, Dmitry Pyzhov. We would need to reconsider who can merge after Fuel PTL/Component Leads elections - fuel-octane-core: needs to be created. Members: Yury Taraday, Oleg Gelbukh, Ilya Kharin - fuel-mirror-core: needs to be created. Sergey Kulanov, Vitaly Parakhin - fuel-upgrade-core: needs to be created. Sebastian Kalinowski, Alex Schultz, Evgeny Li, Igor Kalnitsky - fuel-provision: repo seems to be outdated, needs to be removed. I suggest to make changes in groups first, and then separately address specific issues like removing someone from cores (not doing enough reviews anymore or too many positive reviews, let's say > 95%). I hope I don't miss anyone / anything. Please check carefully. Comments / objections? [1] http://lists.openstack.org/pipermail/openstack-dev/2015-August/072406.html [2] https://review.openstack.org/#/admin/groups/209,members [3] https://review.openstack.org/#/admin/groups/658,members [4] https://review.openstack.org/#/admin/groups/664,members [5] https://review.openstack.org/#/admin/groups/655,members [6] https://review.openstack.org/#/admin/groups/646,members [7] https://review.openstack.org/#/admin/groups/656,members [8] https://review.openstack.org/#/admin/groups/657,members [9] https://review.openstack.org/#/admin/groups/659,members [10] https://review.openstack.org/#/admin/groups/1000,members [11] https://review.openstack.org/#/admin/groups/660,members [12] https://review.openstack.org/#/admin/groups/661,members [13] https://review.openstack.org/#/admin/groups/662,members [14] https://review.openstack.org/#/admin/groups/663,members [15] https://review.openstack.org/#/admin/groups/624,members [16] http://stackalytics.com/report/contribution/fuel-specs/180 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:uns
Re: [openstack-dev] [fuel] PTL & Component Leads elections
t;> > >> [3] https://lwn.net/Articles/648610/ >> > >> >> > >> -- >> > >> Sincerely yours, >> > >> Sergey Lukjanov >> > >> Sahara Technical Lead >> > >> (OpenStack Data Processing) >> > >> Principal Software Engineer >> > >> Mirantis Inc. >> > >> >> > >> >> __ >> > >> OpenStack Development 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 >> > >> >> > >> >> > > >> > > >> > > -- >> > > Yours Faithfully, >> > > Vladimir Kuklin, >> > > Fuel Library Tech Lead, >> > > Mirantis, Inc. >> > > +7 (495) 640-49-04 >> > > +7 (926) 702-39-68 >> > > Skype kuklinvv >> > > 35bk3, Vorontsovskaya Str. >> > > Moscow, Russia, >> > > www.mirantis.com <http://www.mirantis.ru/> >> > > www.mirantis.ru >> > > vkuk...@mirantis.com >> > > >> > > >> __ >> > > OpenStack Development 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 >> > > >> > > >> > >> > >> > -- >> > Davanum Srinivas :: https://twitter.com/dims >> >> > >> __ >> > OpenStack Development 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 >> >> >> __ >> OpenStack Development 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 >> > > > > -- > Davanum Srinivas :: https://twitter.com/dims > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Bugs which we should accept in 7.0 after Hard Code Freeze
Thanks Andrew. Team, if there are any disagreements - let's discuss it. Otherwise, I think we should be just strict and follow defined process. We can deliver high priority bugfixes in updates channel later if needed. I hope that reasoning is clear for everything. Every bugfix has a potential to break something. It's basically a risk. On Mon, Sep 14, 2015 at 8:57 AM Andrew Maksimov <amaksi...@mirantis.com> wrote: > Hi Everyone! > > I would like to reiterate the bugfix process after Hard Code Freeze. > According to our HCF definition [1] we should only merge fixes for > *Critical* bugs to *stable/7.0* branch, High and lower priority bugs > should NOT be accepted to *stable/7.0* branch anymore. > Also we should accept patches for critical bugs to *stable/7.0* branch > only after the corresponding patchset with same ChangeID was accepted into > master. > > [1] - https://wiki.openstack.org/wiki/Fuel/Hard_Code_Freeze > > Regards, > Andrey Maximov > Fuel Project Manager > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node
a better job around providing the > tools > >>>> for a user to get up and running in a timely fashion. Perhaps > providing an > >>>> net-only iso and an all-included iso would be a better solution so > people > >>>> will have their expectations properly set up front? > >>> > >>> > >>> Let me explain why I think having local MOS mirror by default is bad: > >>> 1) I don't see any reason why we should treat MOS repo other way than > >>> all other online repos. A user sees on the settings tab the list of > repos > >>> one of which is local by default while others are online. It can make > user a > >>> little bit confused, can't it? A user can be also confused by the > fact, that > >>> some of the repos can be cloned locally by fuel-createmirror while > others > >>> can't. That is not straightforward, NOT fuel-createmirror UX. > >> > >> > >> > >> I agree. The process should be the same and it should be just another > >> repo. It doesn't mean we can't include a version on an ISO as part of a > >> release. Would it be better to provide the mirror on the ISO but not > have > >> it enabled by default for a release so that we can gather user feedback > on > >> this? This would include improved documentation and possibly allowing a > user > >> to choose their preference so we can collect metrics? > >> > >> > >>> 2) Having local MOS mirror by default makes things much more > convoluted. > >>> We are forced to have several directories with predefined names and we > are > >>> forced to manage these directories in nailgun, in upgrade script, etc. > Why? > >>> 3) When putting MOS mirror on ISO, we make people think that ISO is > equal > >>> to MOS, which is not true. It is possible to implement really flexible > >>> delivery scheme, but we need to think of these things as they are > >>> independent. > >> > >> > >> > >> I'm not sure what you mean by this. Including a point in time copy on an > >> ISO as a release is a common method of distributing software. Is this a > >> messaging thing that needs to be addressed? Perhaps I'm not familiar > with > >> people referring to the ISO as being MOS. > >> > >> > >>> For large users it is easy to build custom ISO and put there what they > >>> need but first we need to have simple working scheme clear for > everyone. I > >>> think dealing with all repos the same way is what is gonna makes things > >>> simpler. > >>> > >> > >> > >> Who is going to build a custom ISO? How does one request that? What > >> resources are consumed by custom ISO creation process/request? Does this > >> scale? > >> > >> > >>> > >>> This thread is not about internet connectivity, it is about aligning > >>> things. > >>> > >> > >> You are correct in that this thread is not explicitly about internet > >> connectivity, but they are related. Any changes to remove a local > repository > >> and only provide an internet based solution makes internet connectivity > >> something that needs to be included in the discussion. I just want to > make > >> sure that we properly evaluate this decision based on end user feedback > not > >> because we don't want to manage this from a developer standpoint. > > > > > > > > +1, whatever the changes is, please keep Fuel as a tool that can deploy > > without Internet access, this is part of reason that people like it and > it's > > better that other tools. > >> > >> > >> -Alex > >> > >> > >> > __ > >> OpenStack Development 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 > >> > > > > > > > > -- > > Yaguang Tang > > Technical Support, Mirantis China > > > > Phone: +86 15210946968 > > > > > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Install fuel-libraryX.Y as a package on slave nodes
issue is with plugins and how to >>> properly handle the distribution of the plugins as they may also include >>> puppet code that needs to be installed on the other nodes for a deployment. >>> Currently I do not believe we install the plugin packages anywhere except >>> the master and when they do get installed there may be some post-install >>> actions that are only valid for the master. Another issue is being >>> flexible enough to allow for deployment engineers to make custom changes >>> for a given environment. Unless we can provide an improved process to >>> allow for people to provide in place modifications for an environment, we >>> can't do away with the rsync. >>> >>> If we want to go completely down the package route (and we probably >>> should), we need to make sure that all of the other pieces that currently >>> go together to make a complete fuel deployment can be updated in the same >>> way. >>> >>> -Alex >>> >>> > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] IRC meeting today
Hi folks, please add topics to the agenda before the meeting: https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda It would be great to discuss: - Critical bugs, and the pipeline of bugs which may become Criticals with larger audience. - Current status of builds from master - Updates on progress in other areas not related to bugs Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Code review process in Fuel and related issues
ots of cross-project > dependencies. That just makes things harder to handle for Fuel, but it's > not a reason to have core reviewers not working on code or non-core > reviewers not doing reviews. > > > * How often OpenStack people are busy on other activities, such as > > helping fellas, troubleshooting customers, participate design meetings > > and so on? > > Quite often. I'm personally on IRC participating in design discussions, > code reviews, and helping people every day. Not troubleshooting > customers, though... > > > If so, do you sure they are humans then? :) I can only speak for > > myself, and that's what I want to say: during 7.0 dev cycle I burned > > in hell and I don't want to continue that way. > > I think you mean you "burned out" :) But, yes, I hear you. I understand > the pressure that you are under, and I sympathize with you. I just feel > that the situation is not an either/or situation, and encouraging some > folks to only do reviews and not participate in coding/feature > development is a dangerous thing. > > Best, > -jay > > > Thanks, > > Igor > > > > On Wed, Sep 2, 2015 at 3:14 PM, Jay Pipes <jaypi...@gmail.com> wrote: > >> On 09/02/2015 03:00 AM, Igor Kalnitsky wrote: > >>> > >>> It won't work that way. You either busy on writing code / leading > >>> feature or doing review. It couldn't be combined effectively. Any > >>> context switch between activities requires an extra time to focus on. > >> > >> > >> I don't agree with the above, Igor. I think there's plenty of examples > of > >> people in OpenStack projects that both submit code (and lead features) > that > >> also do code review on a daily basis. > >> > >> Best, > >> -jay > >> > >> > >> > __ > >> OpenStack Development 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 > > > > > __ > > OpenStack Development 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 > > > > __ > OpenStack Development 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 > -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] Branching strategy vs feature freeze
Dmitry, thank you for getting our conversations and opinions spread across different communications channels collected here in one cohesive email. I like Ruslan's summary, and I support every line of what Ruslan has written here. Note that the two weeks is not really a hard requirement (could be more, or less). In this model you need to come up with a release candidate, which is where we create the release branch, which becomes a stable branch at the end of the cycle. Thierry - I appreciate your feedback. My thinking here is quite similar (if not the same): time required for not merging new functionality should depend on balance between amount of feature-related commits bugfixes. If there # of bugfixes # feature-commits, then I'd say it's too expensive to have two branches with the need to backport every single bugfix. One of the things behind of this branching strategy is to change our engineering processes in such a way, that we simply have more commits related to features and less on bugfixes after FF date. In order to achieve this, I'd expect us to be able to form strong bugfix team which will work across release, so bugs are not collected by FF (and do other incremental improvements). We might want to consider making a flexible date when we create stable branch, based on # of bugfixes vs # of feature-related commits. But frankly, for simplicity, I'd pick the date and work towards it - so everyone's expectations are aligned upfront. Thanks, On Wed, Aug 26, 2015 at 8:44 AM Ruslan Kamaldinov rkamaldi...@mirantis.com wrote: On Wed, Aug 26, 2015 at 4:23 AM, Igor Marnat imar...@mirantis.com wrote: Thierry, Dmitry, key point is that we in Fuel need to follow as much community adopted process as we can, and not to introduce something Fuel specific. We need not only to avoid forking code, but also to avoid forking processes and approaches for Fuel. Both #2 and #3 allow it, making it easier for contributors to participate in the Fuel. #3 (having internal repos for pre-release preparation, bug fixing and small custom features) from community perspective is the same as #2, provided that all the code from these internal repos always ends up being committed upstream. Purely internal logistics. The only one additional note from my side is that we might want to consider an approach slightly adopted similar to what's there in Puppet modules. AFAIK, they are typically released several weeks later than Openstack code. This is natural for Fuel as it depends on these modules and packaging of Openstack. I also think we should go with option #2. What it means to me * Short FF: create stable branch couple of weeks after FF for upstream Fuel * Untie release schedule for upstream Fuel and MOS. This should be two separate schedules * Fuel release schedule should be more aligned with OpenStack release schedule. It should be similar to upstream OpenStack Puppet schedule, where Puppet modules are developed during the same time frame as OpenStack and released just a few weeks later * Internally vendors can have downstream branches (which is option #3 from Dmitry’s email) Thanks, Ruslan __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
As it simply has blocking bugs, and so it can't even be called experimental, only prototype. I don't vote though for reverting the code. I just want to ensure that we don't recommend it to anyone except other developers, who want to try it and may be propose some fixes. On Wed, Aug 19, 2015 at 3:56 PM Vladimir Kuklin vkuk...@mirantis.com wrote: Folks Why not enable it as an experimental? On Wed, Aug 19, 2015 at 12:20 PM, Mikhail Semenov mseme...@mirantis.com wrote: As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
Mikhail, thanks for the update. I'm glad that we have an agreement here, and collaborative decision have been made not to enable something in 7.0 which is proven to be not yet production ready, such late in the release cycle. I'm all for completing this work in 8.0 though. Can you please: - provide an answer on UX, question which I asked in separate email in this same thread - don't even mention MOS going further (neither in subject nor in email), as we are discussing and working with Fuel code here Thank you, On Wed, Aug 19, 2015 at 10:20 AM Mikhail Semenov mseme...@mirantis.com wrote: As we considered today, Ubuntu bootstrap will not be shipped in MOS 7.0. It was a hard decision based on the issue with NICs naming [1]. This bug can be fixed only by changing the naming of network interfaces( http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/) and it's too late to do it in MOS 7.0 scope. So, this feature is moved to MOS 8.0. [1] https://bugs.launchpad.net/mos/+bug/1482049 -- Thanks, Michael On Thu, Aug 13, 2015 at 6:30 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here https://review.openstack.org/#/c/194154/. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu ( http://archive.ubuntu.com/ubuntu) and MOS ( http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: *fuel-bootstrap-image-set ubuntu* 3. Just in a case restart dnsmasq: *dockerctl shell cobbler service dnsmasq restart* 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for *partners* *and* *plugin developers*. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael -- Thanks, Michael __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Great updates to tests and CI jobs
Sounds great. Thank you Roman! I've heard complains about tests not passing for [1]. Now it's passed, so I hope that issues are resolved. [1] https://review.openstack.org/#/c/212906/ On Wed, Aug 19, 2015 at 10:51 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: Indeed, great news! I would only suggest to wait a little bit more that a few days with switching to the voting mode since it looks like there will be not so many patches proposed to python-fuelclient as we are heading towards Hard Code Freeze. I hope that the next step will be to enable Python 3 pipepline for our client so we could finally test all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ OpenStack Development 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 __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] Gerrit dashboard update: ready for core reviewers, disagreements
Thank you Dmitry, everyone can now open review inbox following [1]. Full link was also updated by Dmitry on main Fuel wiki page. [1] http://bit.ly/1LjYO4t On Wed, Aug 12, 2015 at 8:53 PM Cameron Seader cameron.sea...@suse.com wrote: test On 08/12/2015 07:16 PM, Dmitry Borodaenko wrote: Fuelers, I've proposed an update for the Fuel gerrit dashboard: https://review.openstack.org/212231 New Ready for Core Reviewers section encourages peer review by non-cores and allows cores to focus on reviews that already have +1 from other reviews and from CI. New Disagreements section highlights reviews that have both positive and negative code review votes. This worked out pretty well for Puppet OpenStack, lets try to use it in Fuel, too. The remaining sections are rearranged to exclude commits that match the two new sections. -- Dmitry Borodaenko __ OpenStack Development 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 -- Cameron Seader Systems Engineer SUSE c...@suse.com (w)208-572-0095 (M)208-420-2167 Register for SUSECon 2015 www.susecon.com __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Code review process in Fuel and related issues
/presentation/d/1HMSovUxujOUwILPSjiuZHqAxo1TujQazA2yGHSsQC6U [6] https://wiki.openstack.org/wiki/Fuel/Code_Review_Rules [7] https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows [8] https://wiki.openstack.org/wiki/PTL_Guide [9] http://www.quora.com/What-is-Googles-internal-code-review-policy-process [10] https://github.com/docker/docker/blob/master/MAINTAINERS [11] https://adtmag.com/articles/2014/12/17/agile-conflict-resolution.aspx [12] http://stackalytics.com/report/reviews/fuel-library/open [13] http://stackalytics.com/report/contribution/fuel-library/30 [14] http://stackalytics.com/report/contribution/fuel-web/30 [15] http://stackalytics.com/report/reviews/fuel-web/open [16] http://bit.ly/1LjYO4t. Full link is available from Fuel wiki: wiki.openstack.org/wiki/Fuel [17] You should probably be spending at least a couple of hours on code review every day. Not just because the number of code reviewers on a project has the greatest influence on its velocity, but also because its the best way to start building trust with your fellow contributors. If you can show yourself as thoughtful, committed and diligent through your code reviews, then other code reviewers will be much more inclined to prioritize your patches and less carefully scrutinize your work. https://blogs.gnome.org/markmc/2014/06/06/an-ideal-openstack-developer/ [18] https://developer.ibm.com/opentech/2015/03/27/checklist-performing-openstack-code-reviews/ [19] http://stackalytics.com/report/contribution/fuel-group/180 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Get rid of run_test.sh in Fuel Client
+1. Especially if you don't use fake mode of Nailgun, I don't know why would you even be copying legacy code to the new repo.. Thanks! On Mon, Aug 17, 2015 at 6:25 AM Jay Pipes jaypi...@gmail.com wrote: On 08/17/2015 08:50 AM, Roman Prykhodchenko wrote: Hi Fuelers! I was working on enabling Python tests in Fuel Client to run on OpenStack CI and I figured out that we actually have a piece of legacy code which can be removed now. That piece is run_tests.sh file. For those who’s not aware, that script allows to run different tests under different environments. I don’t know how it was a thousand years ago when I was not involved to Fuel project, but the situation at this particular moment looks like that: - Tests are actually orchestrated by tox - The biggest job of run_tests.sh is to translate its options to tox’es options - The only useful job of run_tests.sh is to start Nailgun correctly for functional tests As you can see the profit of that script is tiny. However, the problems it brings are pretty much big and looks as follows: - It is unstable — tiniest changes to tests require big changes to the script - The CLI it provides is confusing - Working on that file looks like doing the same job that is already done in tox - Among the active Fuel Client’s community there are only a few guys who are proficient in bash enough, to support that script effectively My proposal is to extract the code responsible for starting Nailgun into to a small utility script and let tox do the rest by removing run_test.sh completely. That will bring us the following advantages: - No need to support a complex bash script. - Closer to being able to run functional tests on DSVM gates. - Test CLI will be more compatible with other OpenStack projects. I foresee a few questions and the answers for them follow: Q: How is verify-job from FuelCI going to run tests without that file? A: Fuel Client has its own job on FuelCI, so it will be just necessary to change the invocation there. Q: But run_test.sh is in all Fuel projects, shouldn’t we keep them all similar. A: Why does it have to be similar? This kind of difference is minor and it brings more advantages, than just having the same file. In fact the set of options in run_tests.sh is already different from run_tests.sh in fuel-web. Q: Why should we look ad other OpenStack projects? A: Fuel is living in the OpenStack ecosystem so being compatible with it is a big advantage. It’s also a must for going big tent. +1. Just make sure any documentation that might refer to run_tests.sh is updated accordingly :) Best, -jay __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
+ I've just discussed UX for Ubuntu bootstrap in #fuel-dev [1], which doesn't look very clear at the moment. Mikhail - can you please help to clear it up? Namely, can I build Ubuntu bootstrap on Fuel master without direct Internet access? How can I trigger its build (is it from Fuel menu or from master node console?) Thanks, [1] http://irclog.perlgeek.de/fuel-dev/2015-08-17 On Mon, Aug 17, 2015 at 10:08 AM Mike Scherbakov mscherba...@mirantis.com wrote: Hi all, what is the current status of the feature in terms of readiness for production use? I'm wondering as I see a number of bugs, and so we might want to still have it in experimental mode for 7.0, and enable in 8.0. These are the bugs I came across: [1] https://bugs.launchpad.net/fuel/+bug/1485188 [2] https://bugs.launchpad.net/fuel/+bug/1481721 [3] https://bugs.launchpad.net/fuel/+bug/1482242 [4] https://bugs.launchpad.net/fuel/+bug/1483188 [5] https://bugs.launchpad.net/fuel/+bug/1485188 QA team - what is your point of view? Do you see that it's converging to working solution with high level of confidence or not? Some of the bugs seem to be blocking easy scale testing [1,2,4,5]. If it's the case, then I would rather revert back to CentOS-default: we can't block testing at this stage in the release timeline. Thanks, On Mon, Aug 17, 2015 at 12:03 AM Lukasz Oles lo...@mirantis.com wrote: On Mon, Aug 17, 2015 at 7:16 AM, Alexei Sheplyakov asheplya...@mirantis.com wrote: Lukasz, As I see, unfortunatly script which you recommend to use does not use this paths. Instead it have hardcoded values. Actually the script does use the values from the config file (/etc/fuel-bootstrap-image.conf) generated by fuelmenu. Ah, I missed it. Thx Now we need to update paths in two places. Why is that? There are fallback settings in the script so it can work without fuelmenu/config file. Best regards, Alexei On Fri, Aug 14, 2015 at 2:12 PM, Lukasz Oles lo...@mirantis.com wrote: Hello, there is some inconsistency here. Currently I'm fixing bug[1] in fuelmemu. In my fix[2] I changed paths to repos. As I see, unfortunatly script which you recommend to use does not use this paths. Instead it have hardcoded values. Now we need to update paths in two places. Why is that? 1. https://bugs.launchpad.net/fuel/+bug/1484648 2. https://review.openstack.org/#/c/213090/ 3. https://github.com/stackforge/fuel-main/blob/master/fuel-bootstrap-image-builder/bin/fuel-bootstrap-image#L14 Regards On Thu, Aug 13, 2015 at 5:39 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu (http://archive.ubuntu.com/ubuntu) and MOS (http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: fuel-bootstrap-image-set ubuntu 3. Just in a case restart dnsmasq: dockerctl shell cobbler service dnsmasq restart 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for partners and plugin developers. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael __ OpenStack Development 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 -- Łukasz Oleś -- Łukasz Oleś __ OpenStack Development 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 -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel][MOS][Bootstrap] Please try Ubuntu bootstrap in MOS 7.0
Hi all, what is the current status of the feature in terms of readiness for production use? I'm wondering as I see a number of bugs, and so we might want to still have it in experimental mode for 7.0, and enable in 8.0. These are the bugs I came across: [1] https://bugs.launchpad.net/fuel/+bug/1485188 [2] https://bugs.launchpad.net/fuel/+bug/1481721 [3] https://bugs.launchpad.net/fuel/+bug/1482242 [4] https://bugs.launchpad.net/fuel/+bug/1483188 [5] https://bugs.launchpad.net/fuel/+bug/1485188 QA team - what is your point of view? Do you see that it's converging to working solution with high level of confidence or not? Some of the bugs seem to be blocking easy scale testing [1,2,4,5]. If it's the case, then I would rather revert back to CentOS-default: we can't block testing at this stage in the release timeline. Thanks, On Mon, Aug 17, 2015 at 12:03 AM Lukasz Oles lo...@mirantis.com wrote: On Mon, Aug 17, 2015 at 7:16 AM, Alexei Sheplyakov asheplya...@mirantis.com wrote: Lukasz, As I see, unfortunatly script which you recommend to use does not use this paths. Instead it have hardcoded values. Actually the script does use the values from the config file (/etc/fuel-bootstrap-image.conf) generated by fuelmenu. Ah, I missed it. Thx Now we need to update paths in two places. Why is that? There are fallback settings in the script so it can work without fuelmenu/config file. Best regards, Alexei On Fri, Aug 14, 2015 at 2:12 PM, Lukasz Oles lo...@mirantis.com wrote: Hello, there is some inconsistency here. Currently I'm fixing bug[1] in fuelmemu. In my fix[2] I changed paths to repos. As I see, unfortunatly script which you recommend to use does not use this paths. Instead it have hardcoded values. Now we need to update paths in two places. Why is that? 1. https://bugs.launchpad.net/fuel/+bug/1484648 2. https://review.openstack.org/#/c/213090/ 3. https://github.com/stackforge/fuel-main/blob/master/fuel-bootstrap-image-builder/bin/fuel-bootstrap-image#L14 Regards On Thu, Aug 13, 2015 at 5:39 PM, Mikhail Semenov mseme...@mirantis.com wrote: Hi all, We have new feature in the upcoming release MOS 7.0 - Ubuntu-based bootstrap in addition to current CentOS-based one. Design spec can be found here. Current 7.0 ISO contains 2 bootstrap images: CentOS-based (default) and Ubuntu-based. You can easily switch to Ubuntu-based bootstrap using this steps: 1. Make sure the master node can access Ubuntu (http://archive.ubuntu.com/ubuntu) and MOS (http://mirror.fuel-infra.org/mos-repos) APT repositories. 2. Run the following command on the master node: fuel-bootstrap-image-set ubuntu 3. Just in a case restart dnsmasq: dockerctl shell cobbler service dnsmasq restart 4. Reboot the slave nodes. There are only 2 weeks left for testing. On 08/27 we will make a decision about using Ubuntu bootstrap by default in MOS 7.0. It depends on the test results and statistics(more deployments - more confidence). I want to ask everyone to try new Ubuntu bootstrap. Please, deploy it on your environments and file bugs in case of failures. It's most important for partners and plugin developers. Feel free to contact Alexei Sheplyakov(feature lead) and me in case of questions. -- Thanks, Michael __ OpenStack Development 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 -- Łukasz Oleś -- Łukasz Oleś __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel][fuel-library] Librarian changes
: https://review.openstack.org/#/q/status:open+project:stackforge/fuel-library+branch:master+topic:bp/fuel-puppet-librarian,n,z Please raise any concerns as quickly as possible as this is the last call for objections for these reviews. This has been talked about extensively and these reviews have been available for several weeks now. Thanks, -Alex [0] https://review.openstack.org/#/c/202763/ [1] http://paste.openstack.org/show/406523/ [2] http://paste.openstack.org/show/406524/ [3] http://paste.openstack.org/show/406525/ [4] http://paste.openstack.org/show/406526/ [5] http://paste.openstack.org/show/406527/ [6] https://github.com/saz/puppet-ssh/blob/v2.4.0/manifests/server/config.pp#L9 [7] http://paste.openstack.org/show/406536/ [8] https://github.com/puppetlabs/puppetlabs-ntp/compare/3.3.0...4.0.0 [9] http://paste.openstack.org/show/406538/ [10] https://github.com/puppetlabs/puppetlabs-apache/compare/1.2.0...1.3.0 [11] https://github.com/puppetlabs/puppetlabs-firewall/compare/1.0.2...1.2.0 [12] https://review.openstack.org/#/c/92167/ __ OpenStack Development 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 -- Aleksandra Fedorova Fuel CI Engineer bookwar __ OpenStack Development 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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 35bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] Meeting 7/30
We need to discuss: - feature freeze exceptions, current status - librarian - overall bugs status - change SCF date to focus on most important bugs - bugs stalled in in progress state Folks - please add your items to the agenda. On Thu, Jul 30, 2015 at 7:54 AM Andrew Woodward xar...@gmail.com wrote: Please note the IRC meeting is scheduled for 16:00 UTC (about 1 hour from now) in #openstack-meeting-alt Please review meeting agenda and update if there is something you wish to discuss. https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
I'm fine with removing the related code from Fuel then, but I'm not Ok with introducing limitations code. If we don't want to remove the code (and I believe we don't because of backward compatibility reasons), then why don't we just add a warning that this is deprecated / unsopported? And QA will not focus their efforts on this then? On Wed, Jul 29, 2015 at 11:02 AM Sheena Gregson sgreg...@mirantis.com wrote: We restricted this because allowing nova-network to be used as an underlay for all possible combinations added QA time and effort to supporting a soon to be deprecated option. As nova-network is being deprecated upstream and will relatedly be deprecated in Fuel – AFAIK, there is a goal to deprecate nova-network entirely in Fuel 8.0 - we should reduce the number of customers who are even able to use this as the networking underlay to only reflect customers who absolutely require it. There is not sufficient value in supporting nova-network for other use cases. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 29, 2015 12:47 PM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
[openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Get rid of fuelmenu
Guys, how do we deal with use case provide in this bug: https://bugs.launchpad.net/fuel/7.0.x/+bug/1438658 ? Looks like Fuel Menu can't solve this one. Is there workaround possible (even with worse UX)? On Fri, Jul 24, 2015 at 5:26 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Guys, thanks a lot for your opinions. Now it is quite clear for me that vim+text UX is definitely not our way even though many developers (not all) prefer this. Vladimir Kozhukalov On Fri, Jul 24, 2015 at 12:47 AM, Fabrizio Soppelsa fsoppe...@mirantis.com wrote: Hello Vladimir, from me -1. We can discuss if enable fuelmenu=yes or not in grub, but I wouldn't get rid of it. I've never heard complaints against fuelmenu from users, and it's widely used for basic settings afterinstall. If the users had to manually edit another configuration file, should they remember to run a validator tool over it every time after editing the file? Or do we add a futher layer that invokes $EDITOR and after :wq, some validator performs a check...? IMO that's poor UX, and why reimplement it, in fuelmenu there are already nice fixed choices and check commands that restricts potential human mistakes. F. On 07/23/2015 04:23 AM, Vladimir Kozhukalov wrote: Dear colleagues, What do you think of getting rid of fuelmenu and substituting it with thoroughly commented text file + some validation + vim? The major pro of this is that text file is easier to extend and edit. Many people prefer vim UX instead of wandering through the semi-graphical interface. And it is not so hard to implement syntax and logic checking for the text file. Please give your opinions about this. Vladimir Kozhukalov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support.
Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, On Thu, Jul 23, 2015 at 11:53 AM Alexander Makarov amaka...@mirantis.com wrote: Colleagues, I would like to request an exception from the Feature Freeze for Fernet tokens support added to the fuel-library in the following CR: https://review.openstack.org/#/c/201029/ Keystone part of the feature is implemented in the upstream and the change impacts setup configuration only. Please, respond if you have any questions or concerns related to this request. Thanks in advance. -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] librarian-puppet integration, need help with build tasks for fuel-library
__ OpenStack Development 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 -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development 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 __ OpenStack Development 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 __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
Colleagues, it sounds like we need to complete what was requested by Julia here (and it would take about a day as I understand), plus Andrey's request (which seems to be very important for partner story and flexibility), plus additional pieces which turned into bugs [1]. I'd like to hear opinion from fuel-web cores on this. I don't think we can do all of what is requested. [1] https://bugs.launchpad.net/fuel/+bugs?field.tag=feature-node-labels-cli On Thu, Jul 23, 2015 at 6:13 PM Andrey Danin ada...@mirantis.com wrote: Hi, folks. I understand it may be not a good time but I want to make a proposal regarding this feature. The feature may be extremely useful for plugin developers if these labels would be serialized into astute.yaml. They may be used by plugin tasks to do node-specific modifications. Let me provide some examples: * For Xen integration we need to provide unique Xen Server credentials for each Compute node. But with current architecture we don't have any customizable per-node parameters. * It may be possible to use special labels to override global values (i.e. libvirt_type, thus implementing BP https://blueprints.launchpad.net/fuel/+spec/auto-virt-type). * Another case may be the fencing. A user may put IPMI credentials into labels. And there are more cases like that. Despite the original spec doesn't have this idea I propose to implement that. Moreover, I've already did it. Here are my two commits with a spec update [0] and an implementation[1]. They are pretty simple. [0] https://review.openstack.org/#/c/205105/ [1] https://review.openstack.org/#/c/205113/ Please grant FFE to this feature with my additions till tomorrow evening. On Thu, Jul 23, 2015 at 10:05 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Mike, thanks for the important points you've provided. My main argument for this FFE is the following: we've already got a confirmation from SME for this patch. But also got some not critical comments at the last minute before we were going to merge it and have to handle it now. But it looks that these comments don't block the feature and we can fix it after merging a base patch. We tested the patch and it matches an acceptance criteria for the feature with some not critical known issues that already converted to launchpad tickets. I believe we can land it in master tomorrow with +1 from SME. BTW, I see no intersection in reviewers with this patch https://review.openstack.org/#/c/204321/. Thank you, Julia On Thu, Jul 23, 2015 at 9:40 PM Mike Scherbakov mscherba...@mirantis.com wrote: -1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ OpenStack Development 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
Re: [openstack-dev] [Fuel] 7.0 Release - Feature Freeze in action
Thanks Eugene! Congratulations everyone. It was not easy, but we got all essential features merged except a couple of more or less minor parts from them, which require exceptions. Unfortunately, some High priority blueprints didn't make it. Let's see what do we do about exceptions requests. Thanks, On Thu, Jul 23, 2015 at 3:06 PM Eugene Bogdanov ebogda...@mirantis.com wrote: Hello everyone, Please be informed that we have officially entered Feature Freeze state for Fuel 7.0 Release. This means that since now on we focus on bugfixing and stop accepting new code except bugfix commits. If you believe that the code for your feature still needs to be merged as an exception, please file an exception request as described in [1]. 3 Feature Freeze Exception requests have already been filed [2]. We're working closely with Feature Leads and Core Reviewers to assess risks and additional time estimations. We expect to take decisions on all 3 cases by tomorrow EOD Pacific Time and communicate them in respective threads. Thanks everyone for your contributions and collaborative efforts. Let's keep up good work. -- EugeneB [1] https://wiki.openstack.org/wiki/FeatureFreeze [2] Exception requests: #1: Environment Upgrade extensions for Nailgun API: https://review.openstack.org/#/c/192551/ #2: CLI changes of working with custom node labels: *https://review.openstack.org/#/c/204524/ https://review.openstack.org/#/c/204524/* #3: Fernet Tokens support: https://review.openstack.org/#/c/201029/ __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] FF Exception request for Fernet tokens support
Thanks guys. Feature Freeze exception request is declined then. Let's polish this work before the next release, merge changes to upstream puppet-openstack, and then just use librarian in the next release. I'd like to comment Bogdan's email - unless we fully switch to librarian, I don't agree with: Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. We can do whatever we need to do based on immediate needs for Fuel, but with the converging plan. We can't break something in Fuel, for example, just because we need to fix it puppet upstream first. On a separate note, any idea why this email appeared in a new thread in my inbox, not in the original one? My suspect is that Bogdan's client does something weird with email headers... On Fri, Jul 24, 2015 at 10:30 AM Aleksandr Didenko adide...@mirantis.com wrote: Hi, we were not able to get a working deployment with fernet token support patches, mostly due to issues with keys generation and deployment mechanism. I've also spend some time debugging problems with this and I think it's too risky to land it in 7.0. So I vote for postponing it till 8.0. Regards, Alex On Fri, Jul 24, 2015 at 10:17 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Fuel Library team, I expect your immediate reply here. I'd like upgrades team to take a look at this one, as well as at the one which moves Keystone under Apache, in order to check that there are no issues here. -1 from me for this time in the cycle. I'm concerned about: 1. I don't see any reference to blueprint or bug which explains (with measurements) why we need this change in reference architecture, and what are the thoughts about it in puppet-openstack, and OpenStack Keystone. We need to get datapoints, and point to them. Just knowing that Keystone team implemented support for it doesn't yet mean that we need to rush in enabling this. 2. It is quite noticeable change, not a simple enhancement. I reviewed the patch, there are questions raised. 3. It doesn't pass CI, and I don't have information on risks associated, and additional effort required to get this done (how long would it take to get it done) 4. This feature increases complexity of reference architecture. Now I'd like every complexity increase to be optional. I have feedback from the field, that our prescriptive architecture just doesn't fit users' needs, and it is so painful to decouple then what is needed vs what is not. Let's start extending stuff with an easy switch, being propagated from Fuel Settings. Is it possible to do? How complex would it be? If we get answers for all of this, and decide that we still want the feature, then it would be great to have it. I just don't feel that it's right timing anymore - we entered FF. Thanks, I vote -1 for the same reasons. Besides that, this feature seems already partially supported in puppet openstack upstream [0], hence should be developed and finished upstream first. Even if it wasn't at all - we should follow our contribution rules and do not develop features like Fernet tokens or v3 API in our forks. So, the next steps as I see them are: 1) Freeze feature in fuel 2) Submit a spec to openstack puppet to make the feature completed (address revocation, expiration, rotation of the fernet tokens). This also seems related to the already existing blueprint for fuel [1] and the mail thread [2] 3) Implement the feature upstream 4) Backport this to fuel fork in 8.0, or consume it upstream directly in the case the related blueprint [3] will be already implemented by that time. [0] https://review.openstack.org/185441 [1] https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support [2] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069744.html [3] https://blueprints.launchpad.net/fuel/+spec/fuel-puppet-librarian -- Best regards, Bogdan Dobrelya, Irc #bogdando __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev
Re: [openstack-dev] [Fuel] Switching keystone to apache wsgi
Just to ensure that everyone knows - patch is merged. I hope that we will see performance improvements, and looking for test results :) On Thu, Jul 23, 2015 at 1:13 PM Aleksandr Didenko adide...@mirantis.com wrote: Hi, guys, we're about to switch keystone to apache wsgi by merging [0]. Just wanted to make sure everyone is aware of this change. If you have any questions or concerns let's discuss them in this thread. Regards, Alex [0] https://review.openstack.org/#/c/204111/ __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature
Since we are in FF state already, I'd like to have urgent estimate from one of fuel-library cores: - holser - alex_didenko - aglarendil - bogdando aglarendil is on vacation though. Guys, please take a look at https://review.openstack.org/#/c/196114/ - can we accept it as exception? Seems to be good to go... I still think that additional Ceilometer support should be moved to the next release. Thanks, On Thu, Jul 23, 2015 at 1:56 PM Mike Scherbakov mscherba...@mirantis.com wrote: Hi Andrian, this is High priority blueprint [1] for 7.0 timeframe. It seems we still didn't merge the main part [2], and need FF exception for additional stuff. The question is about quality. If we focus on enhancements, then we don't focus on bugs. Which whether means to deliver work with lower quality of slip the release. My opinion is rather don't give FF exception in this case, and don't have Ceilometer support for this new feature. [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role [2] https://review.openstack.org/#/c/196114/ On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote: Hi, The patch patch for fuel-library https://review.openstack.org/#/c/196114/ that implements 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires additional work to do (ceilometer support.), but as far as I can see it doesn't affect any other parts of the product. We plan to implement it in 3 working days (2 for implementation, 1 day for writing system test and test runs), it should not be hard since we already support ceilometer compute agent deployment on controller nodes. We need 1 DevOps engineer and 1 QA engineer to be engaged for this work. So I think it's ok to accept this feature as an exception for feature freeze. Regards, Andrian Noga Project manager Partner Centric Engineering Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Deploy nova-compute (VCDriver) feature
Hi Andrian, this is High priority blueprint [1] for 7.0 timeframe. It seems we still didn't merge the main part [2], and need FF exception for additional stuff. The question is about quality. If we focus on enhancements, then we don't focus on bugs. Which whether means to deliver work with lower quality of slip the release. My opinion is rather don't give FF exception in this case, and don't have Ceilometer support for this new feature. [1] https://blueprints.launchpad.net/fuel/+spec/compute-vmware-role [2] https://review.openstack.org/#/c/196114/ On Thu, Jul 23, 2015 at 1:39 PM Andrian Noga an...@mirantis.com wrote: Hi, The patch patch for fuel-library https://review.openstack.org/#/c/196114/ that implements 'compute-vwmare' role (https://mirantis.jira.com/browse/PROD-627) requires additional work to do (ceilometer support.), but as far as I can see it doesn't affect any other parts of the product. We plan to implement it in 3 working days (2 for implementation, 1 day for writing system test and test runs), it should not be hard since we already support ceilometer compute agent deployment on controller nodes. We need 1 DevOps engineer and 1 QA engineer to be engaged for this work. So I think it's ok to accept this feature as an exception for feature freeze. Regards, Andrian Noga Project manager Partner Centric Engineering Mirantis, Inc Mob.phone: +38 (063) 966-21-24 Email: an...@mirantis.com Skype: bigfoot_ua -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel][CI] Fuel-web CI is broken
Have we resolved this? What is the long term strategy on this? On Mon, Jul 20, 2015 at 10:51 PM Andrew Woodward awoodw...@mirantis.com wrote: I found this after noon that fuel-web CI was broken due to the recent release of oslo.config and oslo.utils 2.0.0 [1] I attempted to muck around with the pinning of the requirements.txt and had initial success with it [2] but later found that it's failing the test_check_requirements_conflicts task. I'm at a loss on how to properly fix the requirements for pbr here. I've also started another commit to get fuel web off of the old namespace [4] [1] https://bugs.launchpad.net/fuel/+bug/1476399 [2] https://review.openstack.org/#/c/203824 [3] https://ci.fuel-infra.org/job/verify-fuel-web/2626/testReport/nailgun.test.unit/test_requirements/test_check_requirements_conflicts/ [4] https://review.openstack.org/#/c/203847/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] Meeting 7/23
I'd like to say a few comments about topics which we didn't have time for: * ubuntu based bootstrap has been merged, needs thorough testing (kozhukalov) great work, thanks Alexei Sheplyakov for working days and nights to get this done. Thanks kozhukalov for helping him out and getting it into master before FF. Let's test it now and see if we can switch it for default in Fuel. Please test Fuel upgrade use case, when old env is on old bootstrap, and new Fuel starts using new bootstrap. Will it be an issue? * Let's switch keystone under Apache right after FF (adidenko) I don't like this. I think we are late for it. It had to be done before FF. We need separate email discussion on this one, I believe, and involvement of puppet-openstack Keystone community. Let's not repeat our mistakes in last release, when we enabled apache but broke keystone on scale. I can't comment on other topics as I don't know much about those, unfortunately. Thanks, On Thu, Jul 23, 2015 at 11:27 AM Andrew Woodward xar...@gmail.com wrote: Yep, forgot to include the topics i referred to Topics not covered in todays meeting, but requested in the agenda * ubuntu based bootstrap has been merged, needs thorough testing (kozhukalov) * Let's switch keystone under Apache right after FF (adidenko) * Separate services from controller status (mattymo) * (?) update iso build process(rpm\deb\repositories\nailgun pinning\IBP) (azvyagintsev) (didn't appear in a meeting) * (?) status of upgrade module = package (azvyagintsev) (didn't appear in a meeting) * Enable deployment through Packer and Vagrant, and/or publish vagrant boxes and Vagrantfiles for standard deployments locally (crimi) (didn't appear in a meeting) On Thu, Jul 23, 2015 at 11:10 AM Andrew Woodward xar...@gmail.com wrote: Today's meeting was a little hectic, if you have a topic on the agenda, ensure you are present and ready to speak, or move your topic lower in the agenda. When possible, pre-type you main points of discussion and copy and paste it into the channel when your topic comes up. This tends to save a bit of time and allows us to move through the topics more quickly. The minutes [2] are available and the following topics where missed. Please raise them in the ML if they should be discussed prior to the next meeting. [1] https://etherpad.openstack.org/p/fuel-weekly-meeting-agenda [2] http://eavesdrop.openstack.org/meetings/fuel/2015/fuel.2015-07-23-16.00.html -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] FFE requests and status
Thanks Andrew. I'd like to add that after there is an announcement about FF, all core reviewers should stop getting patches into master which are parts of features or extensions. We expect only bugfixes. If there is anything else, we need to be very transparent about it, and have them in public place like here. In the past, we had a practice when developers would continue to work on enhancements instead of bugs, and cores would support it. And in fact, FF moves to SCF - and we have to slip our release. Let's not do this again. On Thu, Jul 23, 2015 at 11:56 AM Andrew Woodward xar...@gmail.com wrote: In case you missed it, feature freeze is today and in the rush to merge things, you may have had issues with getting everything landed. For those that are not familiar with the process, to request a feature freeze exception (FFE): * You will need to raise the request to the ML here and in such message - Include [Fuel] FFE request + feature name in the subject - Document what is outstanding (Link to CR's), what's their state - Link to blueprint - Document impact of outstanding changes - Document how long you expect before it can lang * You will also need to get two of the cores in the repo(s) impacted by outstanding reviews to sponsor reviewing the outstanding CR's * Finally PTL will approve each FFE request. Please do not ask for a FFE in this thread I will update this thread with approved FFE's as they occur -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Custom node attributes feature
-1 My concerns are the following: 1. This feature is of a High priority, not Essential [1] 2. We already had to give exception for flexible networking CLI part [2], as it is essential one. So basically that means we have a conflict of focus for SMEs in the area. 3. Just by working on this, we don't spend time on bugs. Which increases risk of delivering on time with expected level of quality +390, -35 LOC also scare me a little bit, it's not a tiny change. One of the possible workarounds can be, if we deliver this patch after HCF, and have an updated package of client. If someone want it in experimental mode, then the one could update client package and have this functionality. If you convince me though that it can be finished by end of the week with only code reviews from SMEs (and only after flexible networking part is done), only after it I can change my mind. [1] https://blueprints.launchpad.net/fuel/+spec/node-custom-attributes [2] https://review.openstack.org/#/c/204321/ On Thu, Jul 23, 2015 at 10:53 AM Sebastian Kalinowski skalinow...@mirantis.com wrote: +1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ OpenStack Development 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 __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] Fwd: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support.
Alexander, as this is purely Fuel related thing, please send a new one with right subject. It has to be [fuel] in subject, and that's it. No MOS, fuel-library, FFE please, we don't use any of those tags. No need to spam Keystone team too, as it's configuration related to Fuel only at this point of time. Thank you, On Thu, Jul 23, 2015 at 10:50 AM Alexander Makarov amaka...@mirantis.com wrote: -- Forwarded message -- From: Alexander Makarov amaka...@mirantis.com Date: Thu, Jul 23, 2015 at 5:30 PM Subject: [MOS] [fuel-library] [keystone] [FFE] FF Exception request for Fernet tokens support. To: Vitaly Sedelnik vsedel...@mirantis.com, Eugene Bogdanov ebogda...@mirantis.com, Igor Marnat imar...@mirantis.com, Ilya Elterman ielter...@mirantis.com, Mike Scherbakov mscherba...@mirantis.com, Roman Alekseenkov ralekseen...@mirantis.com Colleagues, I would like to request an exception from the Feature Freeze for Fernet tokens support added to the fuel-library in the following CR: https://review.openstack.org/#/c/201029/ Keystone part of the feature is implemented in the upstream and the change impacts setup configuration only. Please, respond if you have any questions or concerns related to this request. Thanks in advance. -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP -- Kind Regards, Alexander Makarov, Senior Software Developer, Mirantis, Inc. 35b/3, Vorontsovskaya St., 109147, Moscow, Russia Tel.: +7 (495) 640-49-04 Tel.: +7 (926) 204-50-60 Skype: MAKAPOB.AJIEKCAHDP __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main
+1 On Thu, Jul 23, 2015 at 10:50 AM Evgeniy L e...@mirantis.com wrote: +1 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: At the moment we have several core reviewers for the fuel-main project. Roman Vyalov is responsible for merging of infrastructure-related variables and for the lists of packages. I am responsible for merges in make system. And I have not so much time for digging into makefiles. Vladimir Kozhukalov is responsible for the makesystem for a long time. And now he works on reducing complexity of the system. I do not merge any single patch without his approval. It's time to give formal transfer of responsibility for the fuel-main to him. I nominate Vladimir to fuel-main core. Please reply with +1/-1. __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] [FFE] FF Exception request for Env Upgrade feature
Oleg, considering that your feature is essential for the release, sounds like there is no way we can't give an exception. I'm glad that it's perceived by low risk by core reviewer from Nailgun team (Evgeny). If there are no concerns from other, then we are giving FF exception. However, I'd like to understand how much it will take to finish this work and additional resources required. We need to switch to bugfix work, and the more we continue working on features / enhancements, the less confidence I have that we can meet HCF deadline. Thanks, On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote: Hi, The patch into Nailgun requires additional work to do, but as far as I can see it doesn't affect any other parts of the system, also it's implemented as an extension, which means if the feature will introduce bugs which we won't be able to fix in a required time, it can be easily disabled without removing from master with just removing one line from a file [1] (removing it from extensions list). So I think it's ok to accept environment upgrade feature as an exception for feature freeze. Thanks, [1] https://review.openstack.org/#/c/202969/7/nailgun/nailgun/extensions/base.py On Wed, Jul 22, 2015 at 10:18 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Environment Upgrade extensions added to the Nailgun API [1]. The Nailgun side of the feature is implemented in the following CRs: https://review.openstack.org/#/q/status:open+topic:bp/nailgun-api-env-upgrade-extensions,n,z These changes are implemented as an extension [2] to the Nailgun. It barely touches the core code and doesn't change the existing functionality. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://review.openstack.org/#/c/192551/ [2] https://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z -- Best regards, Oleg Gelbukh __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] SSL feature status
Thanks Stas. My opinion is that it has to be enabled by default. I'd like product management to shine in here. Sheena? On Tue, Jul 21, 2015 at 11:06 PM Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi, we have a spec that says we disable SSL by default and it was successfully merged with that, no one was against such decision. So, if we want to enable it by default now - we can. It should be done as a part of our usual process, I think - I'll create a bug for it and fix it. Current status of feature is next: 1. All codebase for SSL is merged 2. Some tests for it writing my QA - not all of them are done yet. I'll update blueprints as soon as possible. Sorry for inconvenience. On Mon, Jul 20, 2015 at 8:44 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi guys, did we enable SSL for Fuel Master node and OpenStack REST API endpoints by default? If not, let's enable it by default. I don't know why we should not. Looks like we need to update blueprints as well [1], [2], as they don't seem to reflect current status of the feature. [1] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints Stas, as you've been working on it, can you please provide current status? Thanks, -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] SSL feature status
Sergii - I hope there will be no need to turn it off. Let's just enable it asap and tests against it. Thanks, On Wed, Jul 22, 2015 at 8:28 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Sheena, We may turn off SSL right before the release. However, to test it better, I would turn it on. In this case every CI run will be helping to test it better. -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Wed, Jul 22, 2015 at 5:51 AM, Sheena Gregson sgreg...@mirantis.com wrote: I believe the last time we discussed this, the majority of people were in favor of enabling SSL by default for all public endpoints, which would be my recommendation. As a reminder, this will mean that users will see a certificate warning the first time they access the Fuel UI. We should document this as a known user experience and provide instructions for users to swap out the self-signed certificates that are enabled by default for their own internal CA certificates/3rd party certificates. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 22, 2015 1:12 AM *To:* Stanislaw Bogatkin; Sheena Gregson *Cc:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [Fuel] SSL feature status Thanks Stas. My opinion is that it has to be enabled by default. I'd like product management to shine in here. Sheena? On Tue, Jul 21, 2015 at 11:06 PM Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi, we have a spec that says we disable SSL by default and it was successfully merged with that, no one was against such decision. So, if we want to enable it by default now - we can. It should be done as a part of our usual process, I think - I'll create a bug for it and fix it. Current status of feature is next: 1. All codebase for SSL is merged 2. Some tests for it writing my QA - not all of them are done yet. I'll update blueprints as soon as possible. Sorry for inconvenience. On Mon, Jul 20, 2015 at 8:44 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Hi guys, did we enable SSL for Fuel Master node and OpenStack REST API endpoints by default? If not, let's enable it by default. I don't know why we should not. Looks like we need to update blueprints as well [1], [2], as they don't seem to reflect current status of the feature. [1] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints Stas, as you've been working on it, can you please provide current status? Thanks, -- Mike Scherbakov #mihgen -- Mike Scherbakov #mihgen __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates
Folks, I'll push DevOps to run the script. However, what we need is to just go ahead and clean up, abandon manually what is not relevant anymore, provide comment. Please start with your patches. On Thu, Jul 16, 2015 at 11:08 PM Oleg Gelbukh ogelb...@mirantis.com wrote: Nicely put, Doug, you gave me laughs :) I can't see how a CR could hang for a month without anyone paying attention if it worths merging. If this really happens (which I'm not aware of), auto-abandon definitely won't make things any worse. -- Best regards, Oleg Gelbukh On Fri, Jul 17, 2015 at 6:10 AM, Doug Wiegley doug...@parksidesoftware.com wrote: Just adding an experience from another project, Neutron. We had similar debates, and prepping for the long apocalyptic winter of changeset death, Kyle decimated the world and ran the abandon script. The debates were far more intense than the reality, and my large stockpile of Rad-X and Nuka Cola went to waste. Every few weeks, I get a few emails of things being abandoned. And if I care about something, mine or not, I click through and tap ‘Restore’. If one person in the entire community can’t be bothered to click one button, I’m not sure how it’d ever be kept up-to-date, much less merge. Thanks, doug On Jul 16, 2015, at 8:36 PM, Dmitry Borodaenko dborodae...@mirantis.com wrote: I'm with Stanislaw on this one: abandoning reviews just to make numbers *look* better will accomplish nothing. The only benefit I can see is cleaning up reviews that we *know* don't need to be considered, so that it's easier for reviewers to find the reviews that still need attention. I don't see this as that much of a problem, finding stuff to review in Fuel Review Inbox [0] is not hard at all. [0] https://wiki.openstack.org/wiki/Fuel#Development_related_links And the state of our review backlog is such that it's not safe to auto-abandon reviews without looking at them, and if a contributor has spent time looking at a review, abandoning it manually is one click away. If we do go with setting up an auto-abandon rule, it should be extremely conservative, for example: CR has a negative vote from a core reviewer AND there were no comments or positive votes from anyone after that AND it has not been touched in any way for 2 months. On Wed, Jul 15, 2015 at 5:10 PM Mike Scherbakov mscherba...@mirantis.com wrote: Folks, let's execute here. Numbers are still large. Did we have a chance to look over the whole queue? Can we go ahead and abandon changes having -1 or -2 from reviewers for over than a months or so? I'm all for just following standard OpenStack process [1], and then change it only if there is good reason for it. [1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogat...@mirantis.com wrote: 2 weeks seems too small for me. We easy can be in situation when fix for medium bug is done, but SCF starts. And gap between SCF and release easily can be more than a month. So, 2 months seems okay for me if speaking about forcibly applying auto-abandon by major vote. And I'm personally against such innovation at all. On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas dava...@gmail.com wrote: That's a very good plan (Initial feedback/triage) Mike. thanks, dims On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov mscherba...@mirantis.com wrote: +1 for just reusing existing script, and adjust it on the way. No need to immediately switch from infinite time to a couple of weeks, we can always adjust it later. But 1-2 month should be a good start already. Our current stats [1] look just terrible. Before we enable an auto-abandon, we need to go every single patch first, and review it / provide comment to authors. The idea is not to abandon some good patches, and not to offend contributors... Let's think how we can approach it. Should we have core reviewers to check their corresponding components? [1] http://stackalytics.com/report/reviews/fuel-group/open On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins s...@coreitpro.com wrote: Let's keep it at 4 weeks without comment, and Jenkins failed - similar to the script that Kyle Mestery uses for Neutron. In fact, we could actually just use his script ;) https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe
[openstack-dev] [Fuel] SSL feature status
Hi guys, did we enable SSL for Fuel Master node and OpenStack REST API endpoints by default? If not, let's enable it by default. I don't know why we should not. Looks like we need to update blueprints as well [1], [2], as they don't seem to reflect current status of the feature. [1] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints Stas, as you've been working on it, can you please provide current status? Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel Zabbix in deployment tasks
I thought it was done... Stas - do you know anything about it? On Thu, Jul 16, 2015 at 9:18 AM Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, Working on granular deployment, I realized we still call zabbix.pp in deployment tasks. As far as I know zabbix was moved to plugin. Should we remove zabbix from 1. Deployment graph 2. fixtures 3. Tests 4. Any other places Are we going to clean up zabbix code as part of migration to plugin? -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Nominate Denys Klepikov for fuel-docs core
+1 On Thu, Jul 16, 2015 at 8:40 AM Miroslav Anashkin manash...@mirantis.com wrote: +1 -- *Kind Regards* *Miroslav Anashkin**L2 support engineer**,* *Mirantis Inc.* *+7(495)640-4944 (office receptionist)* *+1(650)587-5200 (office receptionist, call from US)* *35b, Bld. 3, Vorontsovskaya St.* *Moscow**, Russia, 109147.* www.mirantis.com manash...@mirantis.com __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Abandon changesets which hang for a while without updates
Folks, let's execute here. Numbers are still large. Did we have a chance to look over the whole queue? Can we go ahead and abandon changes having -1 or -2 from reviewers for over than a months or so? I'm all for just following standard OpenStack process [1], and then change it only if there is good reason for it. [1] https://wiki.openstack.org/wiki/Puppet#Patch_abandonment_policy On Thu, Jul 9, 2015 at 6:27 PM Stanislaw Bogatkin sbogat...@mirantis.com wrote: 2 weeks seems too small for me. We easy can be in situation when fix for medium bug is done, but SCF starts. And gap between SCF and release easily can be more than a month. So, 2 months seems okay for me if speaking about forcibly applying auto-abandon by major vote. And I'm personally against such innovation at all. On Thu, Jul 9, 2015 at 5:37 PM, Davanum Srinivas dava...@gmail.com wrote: That's a very good plan (Initial feedback/triage) Mike. thanks, dims On Thu, Jul 9, 2015 at 3:23 PM, Mike Scherbakov mscherba...@mirantis.com wrote: +1 for just reusing existing script, and adjust it on the way. No need to immediately switch from infinite time to a couple of weeks, we can always adjust it later. But 1-2 month should be a good start already. Our current stats [1] look just terrible. Before we enable an auto-abandon, we need to go every single patch first, and review it / provide comment to authors. The idea is not to abandon some good patches, and not to offend contributors... Let's think how we can approach it. Should we have core reviewers to check their corresponding components? [1] http://stackalytics.com/report/reviews/fuel-group/open On Wed, Jul 8, 2015 at 1:13 PM Sean M. Collins s...@coreitpro.com wrote: Let's keep it at 4 weeks without comment, and Jenkins failed - similar to the script that Kyle Mestery uses for Neutron. In fact, we could actually just use his script ;) https://github.com/openstack/neutron/blob/master/tools/abandon_old_reviews.sh -- Sean M. Collins __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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 -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development 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 __ OpenStack Development 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 -- Mike Scherbakov #mihgen __ OpenStack Development 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
Re: [openstack-dev] [Fuel] Separate repo for Fuel Agent
+1, great to see it is being pushed through. This is not always pleasant work, but it certainly makes our life easier. 130 vs 7275 in fuel-web (fuel-agent-7.0.0-1.mos7275.noarch.rpm) Two questions: a) how our patching suppose to work if we have lower version now? b) why there is mos code name in there, if it's pure Fuel package? Thanks, On Wed, Jul 15, 2015 at 9:12 AM Oleg Gelbukh ogelb...@mirantis.com wrote: Nice work, Vladimir. Thank you for pushing this, it's really important step to decouple things from consolidated repository. -- Best regards, Oleg Gelbukh On Wed, Jul 15, 2015 at 6:47 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: I'm glad to announce that everything about this task is done. ISO build job uses this new repository [1]. BVT is green. Fuel Agent rpm spec has been moved to the new repo and perestroika has also been switched to build fuel-agent package from the new repo. The only difference that could potentially affect deployment is that fuel-agent package built from the new repo will have lower version because the number or commits in the new repo is around 130 vs 7275 in fuel-web (fuel-agent-7.0.0-1.mos7275.noarch.rpm). But I believe it gonna be fine until there are more than one fuel-agent packages in rpm repository. Next step is to remove stackforge/fuel-web/fuel_agent directory. [1] https://github.com/stackforge/fuel-agent.git Vladimir Kozhukalov On Wed, Jul 15, 2015 at 2:19 AM, Mike Scherbakov mscherba...@mirantis.com wrote: Thanks Vladimir. Let's ensure to get it done sooner than later (this might require to be tested in custom ISO..) - we are approaching FF, and I expect growing queues of patches to land... On Tue, Jul 14, 2015 at 6:03 AM Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Dear colleagues, New repository [1] has been created. So, please port all your review requests to stackforge/fuel-web related to Fuel Agent to this new repository. Currently, I am testing these two patches https://review.openstack.org/#/c/200595 https://review.openstack.org/#/c/200025. If they work, we need to merge them and that is it. Review is welcome. [1] https://github.com/stackforge/fuel-agent.git Vladimir Kozhukalov On Fri, Jul 10, 2015 at 8:14 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Ok, guys. Looks like there are no any objections. At the moment I need to create actual version of upstream repository which is going to be sucked in by OpenStack Infra. Please, be informed that all patches changing fuel-web/fuel_agent that will be merged after this moment will need to be ported into the new fuel-agent repository. Vladimir Kozhukalov On Fri, Jul 10, 2015 at 6:38 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Guys, we are next to moving fuel_agent directory into a separate repository. Action flow is going to be as follows: 1) Create verify jobs on our CI https://review.fuel-infra.org/#/c/9186 (DONE) 2) Freeze fuel_agent directory in https://github.com/stackforge/fuel-web (will announce in a separate mail thread). That means we stop merging patches into master which change fuel_agent directory. Unfortunately, all review requests need to be re-sent, but it is not going to be very difficult. 3) Create temporary upstream repository with fuel_agent/* as a content. I'm not planning to move 5.x and 6.x branches. Only master. So, all fixes for 5.x and 6.x will be living in fuel-web. 4) This upstream repository is going to be sucked in by openstack-infra. Patch is here https://review.openstack.org/#/c/199178/ (review is welcome) I don't know how long it is going to take. Will try to poke infra people to do this today. 5) Then we need to accept two patches into new fuel-agent repository: - rpm spec (extraction from fuel-web/specs/nailgun.spec) (ready, but there is no review request) - run_tests.sh (to run tests) (ready, but there is no review request) !!! By this moment there won't be any impact on ISO build process !!! 6) Then we need to change two things at the same time (review is welcome) - fuel-web/specs/nailgun.spec in order to prevent fuel-agent package building https://review.openstack.org/#/c/200595 - fuel-main so as to introduce new fuel-agent repository into the build process https://review.openstack.org/#/c/200025 And good luck to me -) Vladimir Kozhukalov On Wed, Jul 8, 2015 at 12:53 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: There were some questions from Alexandra Fedorova about independent release cycle. according to the configuration [1] Infra team won't be able to do branching or any kind of release management for new repository. Could you please clarify, do we plan to version new repository the same way as we do for main fuel repositories or there going to be separate releases as in python-fuelclient [2]? Who should drive the release process for this repo and how this change will affect Fuel ISO
