Re: [openstack-dev] [Fuel] Nominating Alexander Kislitsky for fuel-web-core
+1 On Wed, Feb 22, 2017 at 12:36 AM Булат Гайфуллин <gaifulli...@gmail.com> wrote: > +1 > > 2017-02-21 17:01 GMT+03:00 Alexey Shtokolov <ashtoko...@mirantis.com>: > > Hey fellow fuelers, > > I'd like to nominate Alexander Kislitsky to the fuel-web-core team. > He's doing thorough review [1], participate in feature developments > (e.g. Config-DB enhancements, network-manager performance > improvements) and made an outstanding contribution bug-fixing. > > Core reviewers, please reply back with +1/-1. > > Thanks, > Ihor > > [1] http://stackalytics.com/?release=ocata=fuel-web > > __ > 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 > -- Fedor Zhadaev email: fzhad...@mirantis.com skype: zhadaevfm IRC: fzhadaev __ 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 Artur Svechnikov to the fuel-web-core team
+1 :) On Thu, Jun 9, 2016 at 12:32 PM Bulat Gaifullin <bgaiful...@mirantis.com> wrote: > +1 > > Regards, > Bulat Gaifullin > Mirantis Inc. > > > > On 09 Jun 2016, at 12:25, Aleksey Kasatkin <akasat...@mirantis.com> wrote: > > Hey Fuelers, > > I'd like to nominate Artur Svechnikov to the fuel-web-core team. > > Artur is doing thorough reviews [1], he produces high-quality code. > Artur is actively participating in features development (implementation > for Dynamically build bootstrap feature, design and implementation for > HugePages support and of NUMA/CPU pinning support) and in bug-fixing in > Fuel project. > > Core reviewers, please reply back with +1/-1. > > [1] http://stackalytics.com/report/contribution/fuel-web/90 > > 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 > > > __ > 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 > -- Kind Regards, Fedor Zhadaev skype: zhadaevfm IRC: fzhadaev __ 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] Nominating Matthew Mosesohn for Fuel Library Core
+1 for Michael :) ср, 2 мар 2016, 17:50 Matthew Mosesohn <mmoses...@mirantis.com>: > Hi all, > > Thank you for the nominations and +1s. I would like to propose Michael > Polenchuk to add as a maintainer to fuel-library to take my spot when > I leave the maintainers list. > > Best Regards, > Matthew Mosesohn > > On Fri, Feb 26, 2016 at 3:54 PM, Kyrylo Galanov <kgala...@mirantis.com> > wrote: > > Finally! +2 ! > > > > On Fri, Feb 26, 2016 at 9:08 PM, Roman Vyalov <rvya...@mirantis.com> > wrote: > >> > >> +1 > >> > >> On Fri, Feb 26, 2016 at 12:31 PM, Aleksey Kasatkin > >> <akasat...@mirantis.com> wrote: > >>> > >>> +1 > >>> > >>> > >>> Aleksey Kasatkin > >>> > >>> > >>> On Thu, Feb 25, 2016 at 11:59 PM, Sergey Vasilenko > >>> <svasile...@mirantis.com> wrote: > >>>> > >>>> +1 > >>>> > >>>> > >>>> /sv > >>>> > >>>> > >>>> > >>>> > __ > >>>> 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 > -- Kind Regards, Fedor Zhadaev skype: zhadaevfm IRC: fzhadaev __ 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] Nominating Matthew Mosesohn for Fuel Library Core
+1 On Wed, Feb 24, 2016 at 5:30 PM Julia Aranovich <jkirnos...@mirantis.com> wrote: > +1 > > On Wed, Feb 24, 2016 at 4:57 PM Denis Egorenko <degore...@mirantis.com> > wrote: > >> I'm not a fuel core member, but i also would like to vote +1 for Matthew. >> He's doing great job! >> >> 2016-02-24 16:02 GMT+03:00 Aleksandr Didenko <adide...@mirantis.com>: >> >>> +1 >>> >>> On Wed, Feb 24, 2016 at 1:50 PM, Vladimir Kuklin <vkuk...@mirantis.com> >>> wrote: >>> >>>> Fellow Fuelers >>>> >>>> I would like to kindly ask you to consider voting for Matthew Mosesohn >>>> as a Fuel Library Core >>>> reviewer. >>>> >>>> Matthew has been working with Fuel since its inception, worked on >>>> countless amount of features, such as : >>>> >>>> Master Node Upgrades and Backup >>>> Improvements to Fuel Infra >>>> Mitaka, Kilo and Juno Support >>>> Detachable Services Plugins >>>> RHOS Support in Fuel >>>> UCA Support >>>> Refactoring of Haproxy and Firewall pieces >>>> >>>> He has also been known as our Fuel Master node and Docker guru and has >>>> been continuously working on bugfixing where he scores as a bug squashing >>>> monster with more than 150 bugfixes to all the parts of Fuel Library (#1 >>>> throughout FL history). >>>> >>>> As you can see, there is not a piece of Fuel Library that he has not >>>> yet gained experience with. >>>> >>>> And this can easily be fetched with simple statistics of Matt's >>>> contribution. He is the topmost contributor to all Fuel projects among all >>>> Fuel Library folks and is the 3rd contributor of Fuel Library. >>>> He also reviews a lot and has a fair amount of -1's (he is not as cruel >>>> as me, though :-)) >>>> >>>> Having that said, I would like to open the vote to promote Matt to >>>> OpenStack Fuel Library core reviewers. >>>> >>>> -- >>>> 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 >>> >>> >> >> >> -- >> Best Regards, >> Egorenko Denis, >> Senior Deployment Engineer >> Mirantis >> __ >> 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 > -- Kind Regards, Fedor Zhadaev skype: zhadaevfm IRC: fzhadaev __ 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 Fedor Zhadaev for the fuel-menu-core team
Thank you! -- Kind Regards, Fedor Zhadaev skype: zhadaevfm IRC: fzhadaev __ 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] Multiple repos UX
e want to verify >>>>>> / handle particular component of this format. Moreover, there's no, >>>>>> for example, priority in Debian repo format. Priority is used by apt >>>>>> preference (not by repo itself). >>>>>> >>>>>> We're talking about Fuel internal representation, and it would be nice >>>>>> to have one internal format across various Fuel projects. >>>>>> >>>>>> >>>>>> > But UI, in my opinion, should follow practices that already exist, >>>>>> not define something new. >>>>>> >>>>>> AFAIU, the idea is to unified internal representation and keep UI as >>>>>> close to distributive standards. >>>>>> >>>>>> On Fri, Dec 11, 2015 at 12:53 PM, Aleksandra Fedorova >>>>>> <afedor...@mirantis.com> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > I agree with the idea of unification for repo configurations, but it >>>>>> > looks like we are developing yet another standard. >>>>>> > >>>>>> > Do we really need a custom format? Why can not we use native format >>>>>> > for yum.conf and apt.sources files, and native tooling (all those >>>>>> > python bindings, cli utils and so on) which is already developed to >>>>>> > work with them? >>>>>> > >>>>>> > On Fri, Dec 11, 2015 at 1:29 PM, Igor Kalnitsky < >>>>>> ikalnit...@mirantis.com> wrote: >>>>>> >> Hey folks - >>>>>> >> >>>>>> >> +1 from my side on the idea of having the unified repo format. It >>>>>> will >>>>>> >> simplify a cross-project contribution. I think we can file a >>>>>> blueprint >>>>>> >> for 9.0. >>>>>> >> >>>>>> >> I have only two questions to discuss: >>>>>> >> >>>>>> >> * We need to declare format for RPM repos either. >>>>>> >> * Shouldn't we use slightly different set of fields for flat >>>>>> Debian repos? >>>>>> >> >>>>>> >> - Igor >>>>>> >> >>>>>> >> On Fri, Dec 11, 2015 at 11:28 AM, Fedor Zhadaev < >>>>>> fzhad...@mirantis.com> wrote: >>>>>> >>> Hello Vladimir, >>>>>> >>> >>>>>> >>> I definitely agree that using one uri for generating number of >>>>>> repos is not >>>>>> >>> the best solution. >>>>>> >>> According to Fuel Menu - there was the discussion in gerrit [1] >>>>>> about >>>>>> >>> repositories format. The first version of my patch implements >>>>>> actually your >>>>>> >>> idea about equality and independence of repositories. It meets >>>>>> disagreements >>>>>> >>> and no one voted for this POV. So I had to change the >>>>>> implementation in >>>>>> >>> favor to the current version. >>>>>> >>> >>>>>> >>> According to this situation I would like to discuss if proposed >>>>>> changes are >>>>>> >>> needed before making new patch. Guys, who took part in the >>>>>> previous patch >>>>>> >>> discussion, please share your opinions. >>>>>> >>> >>>>>> >>> [1] https://review.openstack.org/#/c/242646/ >>>>>> >>> >>>>>> >>> 2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov < >>>>>> vkozhuka...@mirantis.com>: >>>>>> >>>> >>>>>> >>>> Dear colleagues, >>>>>> >>>> >>>>>> >>>> At the moment we have several places where we configure multiple >>>>>> rpm/deb >>>>>> >>>> repositories. Those are: >>>>>> >>>> >>>>>> >>>> Web UI (cluster settings tab) where we define repos for cluster >>>>>> deployment >>>>>> >>>> Fuel-menu (bootstrap section) where we
Re: [openstack-dev] [Fuel] Multiple repos UX
Hello Vladimir,
I definitely agree that using one uri for generating number of repos is not
the best solution.
According to Fuel Menu - there was the discussion in gerrit [1] about
repositories format. The first version of my patch implements actually your
idea about equality and independence of repositories. It meets
disagreements and no one voted for this POV. So I had to change the
implementation in favor to the current version.
According to this situation I would like to discuss if proposed changes are
needed before making new patch. Guys, who took part in the previous patch
discussion, please share your opinions.
[1] https://review.openstack.org/#/c/242646/
2015-12-10 22:47 GMT+03:00 Vladimir Kozhukalov <vkozhuka...@mirantis.com>:
> Dear colleagues,
>
> At the moment we have several places where we configure multiple rpm/deb
> repositories. Those are:
>
>1. Web UI (cluster settings tab) where we define repos for cluster
>deployment
>2. Fuel-menu (bootstrap section) where we define repos for building
>ubuntu bootstrap image
>3. Fuel-mirror where we define repos that are to be cloned (full or
>partial mirrors)
>
> I'd prefer all these places to provide the same UX. By that I mean that
> these components should use the same input data structure like this [0],
> i.e. a flat list of fully independent repositories (see an example below).
> First repo in the list is supposed to be a base OS repo (i.e. contains base
> packages like libc).
>
> [
> {
> type: deb,
> url: some-url,
> section: some-section,
> suite: some-suite,
> priority: some-priority
> },
> {
> type: deb,
> url: another-url,
> section: another-section,
> suite: another-suite,
> priority: another-priority
> },
> ...
> ]
>
> I'd like to focus on the fact that these repositories should be defined
> independently (no base url, no base suite, etc.) That makes little sense to
> speculate about consistency of a particular repository. We only should talk
> about consistency of the whole list of repositories together.
>
> I'll try to explain. In the real world we usually deal with sets of
> repositories which look like this:
>
> http://archive.ubuntu.com/ubuntu/dists/trusty/
> http://archive.ubuntu.com/ubuntu/dists/trusty-updates/
> http://archive.ubuntu.com/ubuntu/dists/trusty-security/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-updates/
> http://mirror.fuel-infra.org/mos-repos/ubuntu/8.0/dists/mos8.0-security/
>
> As you can see these repositories have common hosts and base suites and it
> instills us to think that repositories should not be defined separately
> which is wrong. This special case does not break the whole approach. It is
> just a special case. Repositories are nothing more than just sets of
> packages that can depend on each other forming a tree when taken together.
> Package relation does matter, not repository location, not suite name.
> Parsing package tree for a set of repositories we can easily figure out
> whether this set is consistent or not (e.g. python-packetary allows to do
> this).
>
> Taking into account the above, I'd say UI should allow a user to define
> repositories independently not forcing to use special patterns like suite +
> suite-updates + suite-security, not forcing repositories to be located on
> the same host. That means we should modify fuel-menu bootstrap section
> which currently allows a user to define a base url that is then used to
> form a group of repos (base, base-updates, base-security). Besides, it
> contradicts to our use case when we put mosX.Y locally on the master node
> while mosX.Y-updates and mosX.Y-security are supposed to be available
> online.
>
> What do you guys think of that?
>
>
> [0]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L2006-L2053
>
>
> Vladimir Kozhukalov
>
> __________
> 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
>
>
--
Kind Regards,
Fedor Zhadaev
Skype: zhadaevfm
IRC: fzhadaev
__
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][python-fuelclient] Implementing new commands
__ 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 -- Kind Regards, Fedor Zhadaev Junior Software Engineer, Mirantis Inc. Skype: zhadaevfm E-mail: fzhad...@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
Re: [openstack-dev] [Fuel] Question about unique default hostname for node
Thanks for your answers.
Let me clarify some points:
Sure, we have to validate hostnames during node renaming. And sure we do
it. This issue appears when we already have node with name 'node-X' and new
node is created without providing custom name. I'll give you the example:
1. User has node with hostname 'node-4' (with ID = 4; and there no nodes
with ID 4) ;
2. He renames it in 'node-5' (this name is correct and unique. OK)
3. He adds new node without providing custom hostname.
New node gets ID = 5 (it's primary key and increments automatically)
and default hostname 'node-5'. (Here we have a problem with uniqueness.)
It will be strange if we refuse to create node with default name if
somebody has renamed another node using this name.
About nodes hostnames. Actually we can't refuse to use custom hostnames in
format 'node-{#}' because it is one of the main use cases. So we need to
find the solution which accepts such renaming.
2015-07-22 12:42 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com:
Hi guys,
@Sergii, it looks like you misunderstood something. `node-uuid` is not
a general use case. It's only about conflicting nodes, and I'm sure
everyone's going to change such a hostname in order to avoid
confusion.
@Andrew,
a) Database refuses hostnames that break unique constraint, sot it'll
work out-of-box.
b) I like this idea. I think refusing `node-id` where `id` is not
actually a node id is good idea. It solves our problem.
Thanks,
Igor
On Wed, Jul 22, 2015 at 8:21 AM, Sergii Golovatiuk
sgolovat...@mirantis.com wrote:
node-uuid is very terrible from UX perspective of view. Ask support
people
if they are comfortable to ssh such nodes or telling the name in phone
conversation with customer. If we cannot validate FQDN of hostname I
would
slip this feature to next release where we can pay more attention to
details.
--
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
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@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-dev] [Fuel] Question about unique default hostname for node
Hi all,
The next issue was found during implementation
https://blueprints.launchpad.net/fuel/+spec/node-naming :
User may change node hostname to any another, including default-like
'node-{№}', where № may be bigger than maximum nodeID existing at that
moment.
Later when node with ID == № will be created it's default name
'node-{ID}' will break hostnames uniqueness.
To avoid this now it was decided to generate in such situation another
default hostname.
The current solution is to generate hostname '*node-{UUID}*'. It works, but
may look terribly.
There are a few another possible solutions:
- Use '*node-{ID}-{#}*' format, where *{#} *we'll chose in loop till the
first unique.
- Use some unique value, shorter than UUID (for example - number of
microseconds from current timestamp)
Please share you opinion - what is better?
Also you can propose your own solutions.
--
Kind Regards,
Fedor Zhadaev
Junior Software Engineer, Mirantis Inc.
Skype: zhadaevfm
E-mail: fzhad...@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
