Re: [openstack-dev] [Cinder][Manila]share or volume's size unit

[jun zhong]

I agree with you extend might be one way to solve the problem.

By the way, How about another way that we could import volume
size with float value? such as: 2.5G, 3.4G?

Did community consider about it in the begin?


2017-04-07 20:16 GMT+08:00 Duncan Thomas :

> Cinder will store the volume as 1G in the database (and quota) even if
> the volume is only 500M. It will stay as 500M when it is attached
> though. It's a side effect of importing volumes, but that's usually a
> pretty uncommon thing to do, so shouldn't affect many people or cause
> a huge amount of trouble.
>
> There are also backends that allocate in units greater than 1G, and so
> sometimes give you slightly bigger volumes than you asked for. Cinder
> doesn't not go out if its way to support this; again the database and
> quota will reflect what you asked for, the attached volume will be a
> slightly different size.
>
> In your case, extend might be one way to solve the problem, if you
> backend supports it. I'm not certain what will happen if you ask
> cinder to extend to 1G a volume it already thinks is 1G... if it
> doesn't work, please file a bug.
>
> On 7 April 2017 at 09:01, jun zhong  wrote:
> > Hi guys,
> >
> > We know the share's size unit is in gigabiyte in manila, and volume's
> size
> > unit is also in gigabiyte in cinder, But there is a question that the
> size
> > is not exactly after we migrate tradition enviroment to OpenStack.
> > For example:
> > 1.There is original volume(vol_1) with 500MB size in tradition enviroment
> > 2.We want to use openstack to manage this volume(vol_1)
> > 3.We can only use 1GB volume to manage the original volume(vol_1),
> because
> > the cinder volume size can not support 500MB.
> > How to deal with this? Could we set the volume or share's unit to float
> or
> > something else? or add new unit MB? or just extend the original volume
> size?
> >
> >
> > Thanks
> > jun
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Duncan Thomas
>
> __
> OpenStack Development Mailing 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-dev] [nova] allow_instance_snapshots config option is not used consistently

[Matt Riedemann]

I found a fun little legacy nugget of compute API non-interoperability 
joy tonight.


The "allow_instance_snapshots" config option disables the createImage 
server action API. Completely config driven and therefore not discoverable.


What intrigues me is that this isn't applied to the createBackup or 
shelve APIs, which also create a snapshot of the instance. Is this by 
design? I'm guessing probably not. In fact, this predates the use of 
Gerrit [1] so this was probably just something hacked in so long ago it 
makes zero sense now. The way to disable any of these APIs now is via 
policy.


Unless anyone has an issue with this, I'm going to deprecate it for removal.

[1] 
https://github.com/openstack/nova/commit/9633e9877c7836c18c30b51c8494abfb025e64ca


--

Thanks,

Matt

__
OpenStack Development Mailing 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] [tripleo] PTL on leave next week

[Emilien Macchi]

I'll be in Ann Arbor for the Leadership Training [1], so I'll be away
from keyboard from Monday afternoon to Thursday night.
I might appear from time to time but don't expect me responsive and
helpful during these days.

Some notes though:

1. I'll handle the TripleO Pike-1 release on my free time, so nothing
to do there.

2.stable/ocata OVB jobs are now broken. I spent little time this
weekend to look but I haven't found much, though you can find my notes
here:
https://bugs.launchpad.net/tripleo/+bug/1680996
It would be great if some folks could have a look this week.

3. I'm not sure that I'll be able to chair the weekly meeting, if
someone could volunteer that would be awesome. It's possible that I
appear during the meeting, but not sure.

If there is anything urgent or any decision that needs to be taken,
please refer to Steve Hardy.

Have a great week everyone!
Thanks,

[1] https://etherpad.openstack.org/p/Leadershiptraining
-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [all][elections] TC nomination period is now over

[Tristan Cacqueray]

TC Nomination is now over. The official candidate list is available on
the election website[0].

Starting with this election, there is a new "campaigning" period where
candidates and electorate may debate their statements.

The election will start this Friday.

Thank you,
Tristan

[0]: http://governance.openstack.org/election/#pike-tc-candidates


pgphPWglfVgiK.pgp
Description: PGP signature
__
OpenStack Development Mailing 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] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

[Emilien Macchi]

On Sun, Apr 9, 2017 at 6:36 PM, Stephen Hindle  wrote:
> On Fri, Apr 7, 2017 at 3:00 PM, Doug Hellmann  wrote:
>>
>> Although I was a proponent of having the reload feature address
>> that issue, I'm not sure the complexity of the current implementation
>> is something we want to hang on to. In the new spec, I propose an
>> alternative treatment, which is to not cache mutable values in the
>> first place so the service never needs to receive a signal to reload.
>> The reload API is retained, and simply discards *everything* and
>> starts the configuration object over as though it was being freshly
>> created. This will be a big change, but the feature is new I think
>> the propose behavior better fits the spirit of the need anyway. Please
>> provide feedback if you think otherwise.
>>
>
> I'm still concerned about how this handles non-OpenStack services.
> Kolla currently provides containers for MySQL, RabbitMQ, Ceph, etc.  I
> agree with Paul Belanger, creating a 'special snowflake' for OpenStack
> config would be bad.  Personally, I agree something like confd could
> be used to keep configs 'out' of the containers, by generating them at
> run time.  This could work for both OS and Non-OS services, giving a
> consistent mechanism.

I still don't see anything wrong that would block us to make OpenStack
services talking to etcd directly, while some non-OpenStack services
wouldn't.
In fact, while oslo.db would get the config from etcd, confd (used by
some non-OpenStack services) would also use etcd backend.

The major thing with confd that I don't like is the fact that it uses
Templates files (like Kolla and some other projects are using). We
don't want to maintain templates files as OpenStack options tend to
change every time.
That's one of the major reasons why we think oslo.db could directly
talk to etcd to store the parameters / values.

>
>
> --
> Stephen Hindle - Senior Systems Engineer
> 480.807.8189 480.807.8189
> www.limelight.com Delivering Faster Better
>
> Join the conversation
>
> at Limelight Connect
>
> --
> The information in this message may be confidential.  It is intended solely
> for
> the addressee(s).  If you are not the intended recipient, any disclosure,
> copying or distribution of the message, or any action or omission taken by
> you
> in reliance on it, is prohibited and may be unlawful.  Please immediately
> contact the sender if you have received this message in error.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

[Stephen Hindle]

On Fri, Apr 7, 2017 at 3:00 PM, Doug Hellmann  wrote:
>
> Although I was a proponent of having the reload feature address
> that issue, I'm not sure the complexity of the current implementation
> is something we want to hang on to. In the new spec, I propose an
> alternative treatment, which is to not cache mutable values in the
> first place so the service never needs to receive a signal to reload.
> The reload API is retained, and simply discards *everything* and
> starts the configuration object over as though it was being freshly
> created. This will be a big change, but the feature is new I think
> the propose behavior better fits the spirit of the need anyway. Please
> provide feedback if you think otherwise.
>

I'm still concerned about how this handles non-OpenStack services.
Kolla currently provides containers for MySQL, RabbitMQ, Ceph, etc.  I
agree with Paul Belanger, creating a 'special snowflake' for OpenStack
config would be bad.  Personally, I agree something like confd could
be used to keep configs 'out' of the containers, by generating them at
run time.  This could work for both OS and Non-OS services, giving a
consistent mechanism.



-- 
Stephen Hindle - Senior Systems Engineer
480.807.8189 480.807.8189
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.


__
OpenStack Development Mailing 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] [nova] Proposal to deprecate the os-virtual-interfaces API

[Matt Riedemann]

We've talked about this since Ocata, maybe earlier, but I finally took 
the time to write the spec to deprecate the os-virtual-interfaces API.


Here is the spec:

https://review.openstack.org/455023

Hopefully it makes sense. The proposed change is pretty straight-forward 
and will help us get rid of some more legacy nova-network cruft and 
confusion in the compute API, and also help us to stop proxying to 
Neutron for the os-interface API.


--

Thanks,

Matt

__
OpenStack Development Mailing 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] [election] [tc] TC Candidacy (smcginnis)

[Sean McGinnis]

Hello everyone,

I would like to put my name in for the TC election.

For those of you that don't know me, my name is Sean McGinnis and I have been
the Cinder PTL since the Mitaka release. I have been an operator, consumer,
and developer of infrastructure related services since the late 90's.

I think the role of the TC is more important now than ever. OpenStack is
evolving changing, and the decisions we make now will have a big impact on
where we are a year or more down the road. I would love to be a part of that
and provide my perspective to help shape these decisions.

I've been asked by several people over the last few months for my perspective
on some large companies pulling away from OpenStack or reallocating their
resources elsewhere. While this certainly has an impact on some of the things
we can accomplish, my opinion is that this is actually a good thing. For quite
a while we had some big names dropping a lot of money into the community, with
little return on that investment.

While the loss of some really amazing folks has certainly been felt across the
board, I think this is actually a good thing and something that needed to come
sooner or later. The hype has certainly moved on to other things, but I feel
OpenStack is probably more relevant and useful than ever. With our community
shrinking, this is forcing us to look at what we really need to focus on and
make sure we have a good solid core. I do believe that in the long run,
OpenStack will end up better after going through our current growing pains.

Related to that, I think we do need to start getting a little more opinionated
about some things in the interest of keeping things simple and focused. We
should make it clear what is a core part of OpenStack, and what is a part of
the broader ecosystem.

At the same time, we need to balance encouraging that ecosystem to grow and
thrive. It doesn't matter how well Cinder can create volumes and Nova can spin
up instances if it is too difficult to use build broader solutions on top of.

I'm also a big proponent of closing the loop between those using OpenStack and
those of us building it and setting its direction. I've made it a point to
attend the Operator Midcycles in order to increase this communication. Our
communication between users, operators, and devs is key in making sure we are
focusing those limited resources on addressing the features and issues with
the greatest impact.

Finally, I think education and documentation is a very important component to
all we do. Things like the Upstream University to help new developers get on
board and contributing will be a focus for me going forward. And it doesn't
matter how good of features we implement, if there is no documentation or other
means of educating users about them and how to use them.

So my main thoughts could probably be distilled to:

* Keep things simple as much as possible
* Encourage expansion and interoperability to a wider ecosystem
* Increase communication across all aspects of the community
* Spread knowledge wherever possible

I think mostly we are on the right track for all of these, and I would love to
be part of the TC to be another voice to encourage and direct where we go.

Thank you for considering me for this role!

Sean McGinnis (smcginnis)

__
OpenStack Development Mailing 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] [qa] No meeting next week 13/04

[Andrea Frittoli]

Hi,

a few of us will be off next week, so I'm proposing to cancel the meeting
on Thursday.
Let me know if you have any concern.

andrea
__
OpenStack Development Mailing 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] OSOps Meetings for April

[Melvin Hillsman]

Hey everyone,

Just a friendly reminder that OSOps meetings for April will happen on
Monday April 10th and April 24th at 1400UTC in #openstack-meeting-5

Please feel free to add to the agenda and invite 100 people :)

https://etherpad.openstack.org/p/osops-meeting

You can catch up on previous meeting notes/logs by visiting
http://eavesdrop.openstack.org/meetings/osops

-- 
Kind regards,

Melvin Hillsman
Ops Technical Lead
OpenStack Innovation Center

mrhills...@gmail.com
phone: (210) 312-1267
mobile: (210) 413-1659
http://osic.org

Learner | Ideation | Belief | Responsibility | Command
__
OpenStack Development Mailing 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] [infra][docker] registry-1.docker.io to reverse proxy cache

[Paul Belanger]

On Fri, Apr 07, 2017 at 12:15:49PM -0400, Paul Belanger wrote:
> Greetings,
> 
> In an effort to help projects depending on docker infrastructure, we've setup 
> a
> reverse proxy cache for http://registry-1.docker.io. Please see the
> instructions in 453811[1] on how to configure dockerd to use them.  While
> testing, I did run into an issue with docker 17.04 so suggest you use a lower
> version for now.
> 
> Please reply to the thread when you have a patches propose to use the proxy
> cache. We working to update our configure_mirror.sh[2] so jobs get the URL
> easier, hope to land this today. We'd like to monitor the proxy cache for a 
> few
> jobs first, before opening the flood gates.
> 
> If you have questions, feel free to drop by #openstack-infra or reply.
> 
> [1] https://review.openstack.org/#/c/453811/
> [2] https://review.openstack.org/#/c/454334/
> 
Our configure_mirror.sh script is now live, so you can find your regional
registry by doing the following:

  $ source /etc/ci/mirror_info.sh
  $ echo $NODEPOOL_DOCKER_REGISTRY_PROXY
  http://mirror.iad.rax.openstack.org:8081/registry-1.docker

on any of our zuul workers.

__
OpenStack Development Mailing 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] [election][tc] Nomination for TC

[Ildiko Vancsa]

Hi All,

I would like to throw my hat in the ring to be part of the OpenStack Technical 
Committee.

I'm working for the OpenStack Foundation as Ecosystem Technical Lead where my 
responsibility is to help our members to succeed with OpenStack both as 
software and community. My main focus areas are Telecom/NFV and on boarding new 
contributors.

My OpenStack journey started more than three years ago by adding rich query 
functionality to Ceilometer where I’m currently a core reviewer. By my 
contributions I’m the constant voice of usability and maintainability aspects 
while encouraging collaboration within and between project teams. Among other 
projects I’ve been contributing to Cinder, Nova and OpenStack Manuals[1] as 
well.

I would like to increase diversity in the TC group, but more importantly my 
goal is to add fresh blood to the group driving this community. In my
opinion it is crucial to constantly revisit items from a different perspective 
and let new voices articulate their views and ideas in order to see the big 
picture. Long term this can ensure that OpenStack keeps its adaptability to 
continue to be a smoothly functioning ecosystem providing a stable and 
successful software package.

In the course of my current role within the Foundation I continuously learn 
about the goals and challenges of our ecosystem companies who are productizing, 
distributing and operating OpenStack. As my current focus turns more towards 
Telecom vendors and operators, and NFV and SDN related use cases I see this as 
an area, where notwithstanding the already ongoing great work there is still 
room for further improvements. As a former employee of a Telecom vendor during 
the past few years I saw and experienced the difficulties and even pain of 
trying to find the common language between the two groups and making the 
contributions happen. While the situation is improving, I think it is very 
important to continue to help the Telecom industry in the transformation to fit 
into the cloud terminology and the open source era. By this process OpenStack 
can leverage the advantages that this completely different set of priorities 
and requirements could offer, such as increased stability and advanced 
networking functionality, like how it was demonstrated in Barcelona during the 
keynotes [2].

I’ve been involved in OPNFV [3] for about two years now and I’m also one of the 
ambassadors [4]. I’m continuously working on to find the connection points 
between the two communities [7] to build a large ecosystem which fits 
OpenStack's current priorities in the sense of actively supporting and being 
the foundation for NFV. As part of the TC I would like to continue to help the 
ongoing joint activities to create an interoperability test suite for the NFV 
area and have OPNFV’s CI system integrated with OpenStack to get close to 
immediate feedback while developing new Telecom and NFV related features. As 
the adoption of OpenStack in the Telecom area is continuously growing and 
operators are looking at OpenStack as a main building
block for their systems, I would like to serve as a representative in the 
technical driving force of OpenStack, who can operate as a translator to build 
a common roadmap.

During the past few years I’ve been driving the activities to add the volume 
multi-attach functionality to Nova, which turned into a collaborative activity 
between the two teams to simplify the interaction between the two services. By 
this work we are increasing maintainability of the code bases and stability of 
the services. Driven by the experiences of this work I see cross-project 
collaboration as an area, to further improve. As part of the TC I would like to 
continue driving cross-project activities, where I would like to help with 
making the interactions between the teams
more efficient to ensure end-to-end feature implementation and continuous code 
maintenance and improvement.

I’m also involved in the Upstream Institute activities to provide guidance to 
newcomers to the community. As our community is a continuously changing
environment it is crucial to be welcoming and ensure we distribute the 
knowledge about our services and code base while remaining open to transfer 
responsibilities to newer community members. To help build and maintain this 
mindset, we are building a liaison team to participate in the training 
activities while also have the constant awareness of on-boarding new members to 
the teams. As a TC member I would like to help the project teams to share and 
maintain this mindset to help the contributor ecosystem to remain healthy and 
balanced and our teams to become more efficient. As part of this mission I 
would continue to invest energy in bringing sessions on stage at the OpenStack 
Summits[5][6] to share the lessons I learnt during the past three and a half 
years.

Thank you for reading through my thoughts. It is an honor to be part of 
OpenStack, which is why I would like to take 

[openstack-dev] [Dragonflow] Upcoming weekly meetings

[Omer Anson]

Hi, all.

Due to the local holidays, the following two weekly meetings are cancelled:
* 10th Apr. 2017 (Tomorrow)
* 17th Apr. 2017 (Next week)

Next meeting will take place on the 24th April, 2017.

Sorry for the short notice.

Thank you,
Omer Anson.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev