] https://governance.openstack.org/tc/goals/
>
> On Tue, Jun 20, 2017 at 11:15 AM, Valeriy Ponomaryov <
> vponomar...@mirantis.com> wrote:
>
>> Hello OpenStackers,
>>
>> Wanted to pay some attention to one of restrictions in OpenStack.
>> It came out,
[1] https://bugs.launchpad.net/nova/+bug/1699060
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstac
On Mon, Apr 3, 2017 at 10:00 PM, Ben Swartzlander
wrote:
>
>
> ... and we later gave up on supporting remote ZFS using SSH altogether.
>
> -Ben
No, we didn't. It works. Just have couple of workarounds related to
difference of remote and local shell executors.
--
sage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing Li
n here:
- Should we use only "dash" ( - ) symbols in API names or "underscore" ( _
) is allowed?
- Should we allow both variants at once for each API?
- Should we allow APIs use any of variants and have zoo with various
approaches?
In Manila proje
_
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/ma
> OpenStack Development Mailing 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
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.
replacement for them.
> Please tell me what is new options for that?
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listi
t;
> >
> __________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mail
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
6.611 TRACE oslo_messaging.rpc.dispatcher NoValidHost:
> No valid host was found. Cannot place share
> 48fa7b52-9769-4d85-a62e-a1109a5c9ee3 on devstack@generic1#GENERIC1.
> 2016-04-19 19:46:46.611 TRACE oslo_messaging.rpc.dispatcher
>
>
> What the value should I chose for devstack@generic1#GENERIC1 ?
>
> Thanks,
> Grigoriy
&g
> OpenStack Development Mailing 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
Valeriy Ponomaryov
www.mirantis.com
vpono
> It solves above problem but it creates a new url for a resource
>
> which is child of a earlier created url.
>
> *Is that a problem?*
>
>
>
> Kindly suggest
>
>
>
>
>
> Thanks.
>
> Nidhi
>
>
>
>
>
>
>
>
>
>
>
>
>
>
email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> __
> OpenStack Development Mailing
true for the whole driver interface?
Yes.
> Two instances of the
> driver will never both be asked to do operations on the same share at
> the same time?
Yes.
Each instance of a driver will have its own unique list of shares to be
'ensure'd.
--
Kind Regards
Valeriy
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-
>>> 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 Developmen
; Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> --
> Dustin Schoenbrun
> OpenStack Quality Engineer
> Red Hat, Inc.
> dscho...@redhat.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/listi
t; __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.opens
Hello John,
If I am not mistaken, none of existing Third-Party CIs run scenario tests.
So, it can not be the blocker for you. It is true to say that, for the
moment, API tests is enough for Third-Party CI.
Regards,
Valeriy Ponomaryov
On Thu, Dec 3, 2015 at 1:38 PM, John Spray wrote:
>
e.ini" and then run
Liberty Manila API service.
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@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 question
Hello Emmanuel,
There is no strong reason to keep it disabled. Thanks for pointing this
out.
I agree that it is better to have enabled.
So, I already did a change for it - https://review.openstack.org/#/c/200585/
Regards,
Valeriy Ponomaryov
On Wed, Jul 8, 2015 at 12:10 PM, Emmanuel Cazenave
he question arises if it's acceptable.
>
>
> Regards
> Csaba
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:un
soon as there is big community for these projects.
It worth to try, IMHO.
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
Deepak,
"transfer-*" is not suitable in this particular case. Usage of share
networks causes creation of resources, when "transfer" does not. Also in
this topic we have "creation" of new share based on some snapshot.
Valeriy
On Sun, May 31, 2015 at 4:23 PM, Deepak Shetty wrote:
>
> On Thu, May
e forced to rework logic of share
servers creation for driver he maintains.
Also, how many back-ends are able to support such feature?
Regards,
Valeriy Ponomaryov
__
OpenStack Development Mailing List (not for usage questions)
ossible to avoid creation of
"temporary share" DB record and use this data storage for storing all
required data per each share.
Please, look at it, and provide feedback, whether such approach can be used
in your case or not and why.
[1] - https://review.openstack.org/#/c/176877/
Ki
Hello, Joe
It is bug, "region_name" is not used as should be. Feel free to file a bug
for it.
Kind Regards
Valeriy Ponomaryov
On Thu, Apr 30, 2015 at 8:23 PM, Joe Meadows wrote:
> Hi,
>
> I work for Hitachi Data Systems (HDS) and am developing Manila support for
>
_
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/o
+1
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
No user-facing changes. Only under-the-hood improvement. I think result
worth passing of FFE.
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
__
OpenStack Development Mailing List (not for usage
scribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
Hello Jason,
On Tue, Feb 10, 2015 at 10:07 AM, Jason Bishop
wrote:
>
> When a share is created (from scratch), the manila scheduler identifies a
> share server from its list of backends and makes an api call to
> create_share method in the appropriate driver. The driver executes the
> required s
Hello Jake,
Main thing, that should be mentioned, is that blueprint has no assignee.
Also, It is created long time ago without any activity after it.
I did not hear any intentions about it, moreover did not see some, at
least, drafts.
So, I guess, it is open for volunteers.
Regards,
Valeriy
his saying: I create share without
> share-server. But, the truth is just share-server is not handled by manila,
> doesn't mean it not exist. E.g. in glusterFS, the share-server is
> "self.gluster_address".
>
>
>
> So, I suggest to edit ShareManager code to get share_server be
According to (2) - yes, analog of Cinder's "manage/unmanage" is not
implemented in Manila yet.
On Wed, Dec 3, 2014 at 9:03 AM, Marc Koderer wrote:
> Hi Valeriy,
>
> thanks for feedback. My answers see below.
>
> Am 02.12.2014 um 16:44 schrieb Valeriy Ponomaryo
nionfs live?
>
> Thanks,
> Kevin
> ------
> *From:* Valeriy Ponomaryov [vponomar...@mirantis.com]
> *Sent:* Tuesday, December 02, 2014 7:44 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Haub, Stefan; Lichtenstein, Thomas
> *Subj
looks like not implemented.
6) Implemented.
7) Not implemented yet.
8) No "cloning", but we have snapshot-approach as for volumes in cinder.
Regards,
Valeriy Ponomaryov
Mirantis
On Tue, Dec 2, 2014 at 4:22 PM, Marc Koderer wrote:
> Hello Manila Team,
>
> We identified use cases
s ?
>
> thanx,
> deepak
>
>
> _______
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomar...@mirantis.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
But why "policy" is being discussed on "quota" thread?
On Wed, Oct 15, 2014 at 11:55 AM, Valeriy Ponomaryov <
vponomar...@mirantis.com> wrote:
> Manila project does use "policy" common code from incubator.
>
> Our "small" wra
ely
>>> >>>>>>>> sure we
>>> >>>>>>>> want to make it a "required" component for every deployment.
>>> Perhaps
>>> >>>>>>>> single
>>> >>>&
enstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
--version
> pip 1.5.6 from /usr/lib/python2.7/site-packages (python 2.7)
> [stack@devstack-large-vm manila]$ tox --version
> 1.7.2 imported from /usr/lib/python2.7/site-packages/tox/__init__.pyc
> [stack@devstack-large-vm manila]$ virtualenv --version
> 1.11.6
>
> ===
... and that just gets confusing. :-)
>
> [1] https://wiki.openstack.org/wiki/RefStack/TCup
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/c
Github has file size limit in 100 Mb, see
https://help.github.com/articles/what-is-my-disk-quota
Our current image is about 300 Mb.
On Tue, Aug 5, 2014 at 11:43 PM, Swartzlander, Ben <
ben.swartzlan...@netapp.com> wrote:
> On Tue, 2014-08-05 at 23:13 +0300, Valeriy Ponomaryov wrote:
ve any suggestions for more suitable file storage to use?
--
Kind Regards
Valeriy Ponomaryov
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
I disagree to moving this logic to "tempest/services/*". The idea of these
modules - assemble requests and return responses. Testing and verification
should be wrapped over it. Either base class or tests, it depends on
situation...
--
Kind Regards
Valeriy Ponomaryov
On Thu, Mar 13,
51 matches
Mail list logo
