Huge +1. I actually have some knowledge about how transactions work in
Nailgun, and the saddest is that the worst parts are Network Managers and
garbage code in various task helpers. Please add me to discussions on
topic, I'm back from vacation on Thursday.
18 Май 2015 г. 18:17 пользователь "Alexan
Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
>
> On Wed, Apr 29, 2015 at 5:48 PM, Igor Kalnitsky
> wrote:
>
>> Hello,
>>
>> If all is ok, let's move bug to 7.0 and fix it with netaddr as it was
>> proposed in comments to the ticket.
>>
Hi everybody, does anybody besides Mellanox need this? If not and while
it's already solved issue for Mellanox itself - let's just close the bug as
won't fix for now.
On Wed, Apr 29, 2015 at 11:16 AM, Andrey Danin wrote:
> Hi, Sylwester,
>
> Fuel-plugin-mellanox is in development stage now, so
er fit into these
requirements.
On Tue, Apr 7, 2015 at 12:52 PM, Roman Prykhodchenko wrote:
> This is also relevant for python-fuelclient.
>
> 6 квіт. 2015 о 12:27 Nikolay Markov написав(ла):
>
> Hello everyone,
>
> I know this is really low priority and so on, but here
Hello everyone,
I know this is really low priority and so on, but here is this bug about
moving to the newest version of "hacking" package:
https://bugs.launchpad.net/fuel/+bug/1410810 . And here is the log after
all pep8 linters and checks:
https://fuel-jenkins.mirantis.com/job/verify-fuel-web/70
+1
29 Мар 2015 г. 20:42 пользователь "Sergey Vasilenko" <
svasile...@mirantis.com> написал:
> +1
>
>
> /sv
>
> On Fri, Mar 27, 2015 at 5:31 PM, Anastasia Urlapova <
> aurlap...@mirantis.com> wrote:
>
>> + 10
>>
>> On Fri, Mar 27, 2015 at 4:28 AM, Igor Zinovik
>> wrote:
>>
>>> +1
>>>
>>> On 26 Mar
+1 from me also
On Thu, Mar 19, 2015 at 1:07 PM, Roman Prykhodchenko wrote:
>
> https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z
>
> 17 бер. 2015 о 18:51 Mike Scherbakov
> написав(ла):
>
> Roman,
> it would be g
We already run unit tests only using real Postgresql. But
this still doesn't answer the question how we should test migrations.
On Fri, Mar 6, 2015 at 5:24 PM, Boris Bobrov wrote:
> On Friday 06 March 2015 16:57:19 Nikolay Markov wrote:
> > Hi everybody,
> >
> > F
Hi everybody,
>From time to time some bugs appear regarding failed database migrations
during upgrade and we have High-priority bug for 6.1 (
https://bugs.launchpad.net/fuel/+bug/1391553) on testing this migration
process. I want to start a thread for discussing how we're going to do it.
I don't
Sebastian, it was mostly on some internal meetings. I think Roman
Prykhodchenko was going to participate and shine some light on topic.
On Mon, Feb 9, 2015 at 4:03 PM, Sebastian Kalinowski
wrote:
> Hi,
>
> 2015-02-09 13:57 GMT+01:00 Nikolay Markov :
>>
>> They say, there is
Hello colleagues,
They say, there is some kind of "holywar" around the topic on if
fuel-client tests should rely on working Nailgun API without mocking
it. This is also connected with API stabilizing and finally moving
fuel-client to a separate library which may be used by any third-party
projects
> order to drop legacy) and introduce new implementation when we need.
>
> Thanks,
> Igor
>
> On Tue, Jan 27, 2015 at 11:12 AM, Nikolay Markov wrote:
>> Guys,
>>
>> I'm now here and I don't agree that we need to remove "changes"
>> att
Guys,
I'm now here and I don't agree that we need to remove "changes"
attribute. On the opposite, I think this is the only attribute which
should be looked at on UI and backend, and all these
"pending_addition" and "pending_someotherstuff" are obsolete and
needless.
Just assume, that we'll soon h
I also wanted to add that there is a PR already on adding plugins
repos to stackforge: https://review.openstack.org/#/c/147169/
There is a battle in comments right now, because some people are not
agree that so many repos are needed.
On Fri, Jan 23, 2015 at 1:25 AM, Mike Scherbakov
wrote:
> Hi F
It's also should be mentioned that these are several changes to do on
backend in order for UI to work faster, not on UI itself. For example,
these are:
- Custom filters, as Vitaly mentioned
- Pagination of collections
- PATCH requests support
- Probably both short and /full representations for som
ly accommodate with changes to Pecan (I've done so with several
>> OpenStack
>> projects in the past).
>> On 12/08/14 02:10 PM, Nikolay Markov wrote:
>> > > Yes, and it's been 4 days since last message in this thread and no
>> > > objections, so it
> Yes, and it's been 4 days since last message in this thread and no
> objections, so it seems
> that Pecan in now our framework-of-choice for Nailgun and future
> apps/projects.
We still need some research to do about technical issues and how easy
we can move to Pecan. Thanks to Ryan, we now have
;>> Choosing the right instrument for the job in an open source community
>>> involves choosing technologies that the community is familiar/comfortable
>>> with as well, as it will allow you access to a greater pool of developers.
>>>
>>> With that in min
community principles, I'm just
trying to choose the right instrument for the job.
On Wed, Dec 3, 2014 at 7:41 PM, Jay Pipes wrote:
> On 12/03/2014 10:53 AM, Nikolay Markov wrote:
>>>
>>> However, the OpenStack community is also about a shared set of tools,
>>> devel
fN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing
On Wed, Dec 3, 2014 at 6:53 PM, Nikolay Markov wrote:
>> However, the OpenStack community is also about a shared set of tools,
>> development methodologies, and common perspectives.
>
> I completely agree with you, Jay, but the same principle may be
&g
On Wed, Dec 3, 2014 at 6:32 PM, Jay Pipes wrote:
> On 12/03/2014 10:16 AM, Nikolay Markov wrote:
>>
>> It would be great to look at some obvious points where Pecan is better
>> than Flask despite of the fact that it's used by the community. I
>> still don't
It would be great to look at some obvious points where Pecan is better
than Flask despite of the fact that it's used by the community. I
still don't see a single and I don't think the principle "jump from
the cliff if everyone does" works well in such cases.
On Wed, Dec 3, 2014 at 5:53 PM, Jay Pip
Dear colleagues,
We surely may take into account the beauty of the code in both cases
(as for me, Pecan loses here, too) and argue about global objects and
stuff, but I'm trying to look at amount of men and time we need to
move to one of these frameworks.
I wouldn't say our API is badly designed,
like you need to pay off technical debt and clean up your
> API.
>
> Michael
>
> On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov
> wrote:
>>
>> Hello all,
>>
>> I actually tried to use Pecan and even created a couple of PoCs, but
>> there due to histor
Hello all,
I actually tried to use Pecan and even created a couple of PoCs, but
there due to historical reasons of how our API is organized it will
take much more time to implement all workarounds we need to issues
Pecan doesn't solve out of the box, like working with non-RESTful
URLs, reverse URL
checkbox (or more complicated
>>> controls) for the settings tab. Why change this approach for plugins? The
>>> settings tab (cluster attributes) currently is a SSOT
>>> <http://en.wikipedia.org/wiki/Single_Source_of_Truth>, and you want to
>>> ruin it for no
mixin and if you want to check
> this checkbox to determine whether to perform some action or not and don't
> want to write any python code, try to add to plugin's YAML "restrictions"
> section which we already have for the settings tab, the wizard and roles.
>
>
ty, like Sahara, Murano right
> now - checkboxes would be simply required.
> It works this way right now, and it doesnot look like huge overhead.
>
> So what do you think, will it work or no?
>
> On Wed, Oct 8, 2014 at 8:42 AM, Nikolay Markov wrote:
>>
>> Hi,
>>
Hi,
Frankly speaking, I'm not sure on how 1st approach will even work.
What if plugin doesn't provide any checkboxes (and in most cases it
won't)? How should we determine in serializer, which plugins should be
applied while generating astute.yaml and tasks.yaml? Should we
autogenerate some stuff f
Probably, even "experimental feature" should at least pretend to be
working, anyway, or it shouldn't be publically announced. But I think
it's important to describe limitation of this features (or mark some
of them as "untested") and I think list of known issues with links to
most important bugs is
Hi colleagues,
We had a meeting with LSI guys yesterday, discussing status of this feature
as a possible Fuel/Nailgun plugin. There was no final decision, but there
are two possible ways to simplify our integration:
- LSI team can continue modifying Fuel itself, but with strong targeting on
futur
Hi,
Our team run into some serious trouble with performance of
'swift-ring-builder rebalance' after some recent changes. On our
environment it takes about 8 minutes, and this and it is not the
maximum. This is really blocker for us.
This issue is reproducible on Ubuntu 12.04 + Python 2.7. The fun
32 matches
Mail list logo
