Thanks Lakshmi, that's useful.
So, we want to release Artifacts API in Kilo as experimental. We do need
some early adopters to begin working with it (the initial interest was from
Heat and Murano projects, and the OVA/OVF initiative for Images as well) in
the next cycle and provide some feedback
On 3/12/15, 09:26, Daniel P. Berrange berra...@redhat.com wrote:
On Thu, Mar 12, 2015 at 09:07:30AM -0500, Flavio Percoco wrote:
On 11/03/15 15:06 -1000, John Bresnahan wrote:
FWIW I agree with #3 and #4 but not #1 and #2. Spelling is an easy
enough
thing to get right and speaks to the
+2A :P (Daniel and Ian)
Thanks,
-Nikhil
From: Ian Cordasco ian.corda...@rackspace.com
Sent: Thursday, March 12, 2015 10:59 AM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [Glance
On 03/12/2015 01:19 PM, Sampath, Lakshmi wrote:
We had a discussion with API WG today about what it means to be an EXPERIMENTAL
API and here's the takeway from that discussion.
All experimental means with regards to an API is we reserve the right
to completely abandon this or change it in
On Thu, Mar 12, 2015 at 1:42 PM, Brian Rosmaita
brian.rosma...@rackspace.com wrote:
I don't know how elaborate we want to get here, but Everett Toews had an
interesting suggestion in the openstack-api channel. It would go something
like this:
(1) User gets /x1/search endpoint from service
This would require some changes to how python-glanceclient parses
versions. Even if the keystone catalog has a version string in it (which
typically is not the case for glance) the version parsing in common/utils
only recognizes version strings beginning with 'v'.
Would it be sensible to add
I don't know how elaborate we want to get here, but Everett Toews had an
interesting suggestion in the openstack-api channel. It would go something
like this:
(1) User gets /x1/search endpoint from service catalog
(2) User does some request against /x1/search
(3) User receives 400 with an error
On Mar 12, 2015, at 1:42 PM, Brian Rosmaita brian.rosma...@rackspace.com
wrote:
I don't know how elaborate we want to get here, but Everett Toews had an
interesting suggestion in the openstack-api channel. It would go something
like this:
(1) User gets /x1/search endpoint from service
(not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
time.
+1 to consistent time.
Both 1400 and 1500 work me.
-Hemanth
From: Ian Cordasco ian.corda...@rackspace.com
Sent: Wednesday, March 11, 2015 10:25 AM
From: Louis Taylor lo...@kragniz.eu
Sent: Wednesday, March 11, 2015 10:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
On Wed, Mar 11, 2015 at 02:25:26PM +, Ian Cordasco
FWIW I agree with #3 and #4 but not #1 and #2. Spelling is an easy
enough thing to get right and speaks to the quality standard to which
the product is held even in commit messages and comments (consider the
'broken window theory'). Of course everyone makes mistakes (I am a
terrible speller)
: 11 March 2015 20:40
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
time.
I'd prefer to go with 1400 UTC unless there's a majority for 1500UTC.
P.S. It's my feeling that ML announcements and conversations
meeting and merge the votes.
Thanks,
-Nikhil
From: Louis Taylor lo...@kragniz.eu
Sent: Wednesday, March 11, 2015 10:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance
@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] Nitpicking in code reviews
FWIW I agree with #3 and #4 but not #1 and #2. Spelling is an easy
enough thing to get right and speaks to the quality standard to which
the product is held even in commit messages and comments (consider the
'broken
On Wed, Mar 11, 2015 at 02:25:26PM +, Ian Cordasco wrote:
I have no opinions on the matter. Either 1400 or 1500 work for me. I think
there are a lot of people asking for it to be at 1500 instead though.
Would anyone object to changing it to 1500 instead (as long as it is one
consistent
I have no opinions on the matter. Either 1400 or 1500 work for me. I think
there are a lot of people asking for it to be at 1500 instead though.
Would anyone object to changing it to 1500 instead (as long as it is one
consistent time for the meeting)?
On 3/11/15, 01:53, Inessa Vasilevskaya
From: Gary Kotton gkot...@vmware.com
Sent: Sunday, March 8, 2015 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote
Oh, it means 3:00AM for me :-(
On 09/03/15 09:07, Nikhil Komawar wrote:
Hi all,
Currently, we've alternating time for Glance meetings. Now, with the
Daylight savings being implemented in some parts of the world, we're
thinking of moving the meeting time to just one slot i.e. earlier
On Sun, Mar 08, 2015 at 08:07:33PM +, Nikhil Komawar wrote:
So, the new proposal is:
Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on
#openstack-meeting-4
+1
It was nice to try out the alternating meeting times. However, I don't think it
brought many benefits,
: Gary Kotton gkot...@vmware.com
Sent: Sunday, March 8, 2015 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote:
On 07/03/15 23:16 +, Nikhil Komawar wrote
Works for me, but the previous one worked as well. So, consider my vote as
+1 unless the majority is against this :)
--
Regards,
Alexander Tivelkov
On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang feil...@catalyst.net.nz
wrote:
Oh, it means 3:00AM for me :-(
On 09/03/15 09:07, Nikhil
7:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
I like the idea of a 'core-member'. But, how are core-members different from
core-reviewers? For instance, with core-reviewers it is very clear that these
are folks you
Thanks Nikhil,
To have a single whiteboard for all the Artifacts reviews we've created an
etherpad [1]
Here we track the progress of all the 7 artifact-releated changesets and
all the unresolved issues found there. As agreed earlier, non-critical
issues (i.e. the issues which do not affect
: Hemanth Makkapati hemanth.makkap...@rackspace.com
Sent: Friday, March 6, 2015 7:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
I like the idea of a 'core-member'. But, how are core-members different
from
core-reviewers
, at least for the time being!
Cheers
-Nikhil
From: Hemanth Makkapati hemanth.makkap...@rackspace.com
Sent: Friday, March 6, 2015 7:15 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
I
.
-Hemanth.
From: Nikhil Komawar nikhil.koma...@rackspace.com
Sent: Friday, March 6, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
Thank you all for the input outside of the program
On 3/5/15, 10:56, Dr. Jens Rosenboom j.rosenb...@x-ion.de wrote:
Am 05/03/15 um 17:37 schrieb Ian Cordasco:
The clients in general do not back port patches. Someone should work
with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the
On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.com
wrote:
I like that idea. Can you start it out with Nova or Neutron’s guidelines?
FYI, the core reviewer guidelines for Neutron are in-tree now [1], along
with all of our other policies around operating in Neutron [2].
I like that idea. Can you start it out with Nova or Neutron’s guidelines?
On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote:
I think yes, it does. But I mean that now we're writing a document called
Glance Review Guidelines
rotation in the following weeks.
Hope it works!
Regards,
-Nikhil
From: Kyle Mestery mest...@mestery.com
Sent: Friday, March 6, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations
: Friday, March 6, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco
ian.corda...@rackspace.com wrote:
I like that idea. Can you start it out with Nova or Neutron’s
for taking care of this,
Flavio
Regards,
-Nikhil
From: Kyle Mestery mest...@mestery.com
Sent: Friday, March 6, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.
On Fri
Am 05/03/15 um 17:52 schrieb Doug Hellmann:
On Thu, Mar 5, 2015, at 11:37 AM, Ian Cordasco wrote:
The clients in general do not back port patches. Someone should work with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the client
On 03/05/2015 12:02 AM, Nikhil Komawar wrote:
The python-glanceclient release management team is pleased to announce:
python-glanceclient version 0.16.1 has been released on Thursday, Mar 5th
around 04:56 UTC.
For more information, please find the details at:
On Thu, Mar 5, 2015, at 03:15 PM, Dr. Jens Rosenboom wrote:
Am 05/03/15 um 17:52 schrieb Doug Hellmann:
On Thu, Mar 5, 2015, at 11:37 AM, Ian Cordasco wrote:
The clients in general do not back port patches. Someone should work with
stable-maint to raise the cap in Icehouse and Juno. I
I think yes, it does. But I mean that now we're writing a document called
Glance Review Guidelines
https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5RJabsI/edit?usp=sharing
and it has a section For cores. It's easy to include some concrete rules
there to add more clarity.
The clients in general do not back port patches. Someone should work with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the client breaking other projects.
Proposals can be made though and ideally, openstack/requirements’ gate
jobs will
On Thu, Mar 5, 2015, at 11:37 AM, Ian Cordasco wrote:
The clients in general do not back port patches. Someone should work with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the client breaking other projects.
Proposals can be made
Am 05/03/15 um 17:37 schrieb Ian Cordasco:
The clients in general do not back port patches. Someone should work with
stable-maint to raise the cap in Icehouse and Juno. I suspect, however,
that those caps were added due to the client breaking other projects.
Proposals can be made though and
On 3/4/15 11:31 PM, Thierry Carrez wrote:
Flavio Percoco wrote:
[...]
I personally don't think adding new cores without cleaning up that
list is something healthy for our community, which is what we're
trying to improve here. Therefore I'm still -2-W on adding new folks
without removing
Flavio Percoco wrote:
[...]
I personally don't think adding new cores without cleaning up that
list is something healthy for our community, which is what we're
trying to improve here. Therefore I'm still -2-W on adding new folks
without removing non-active core members.
It's also *extremely*
Yes, it's absolutely right. For example, Nova and Neutron have official
rules for that:
https://wiki.openstack.org/wiki/Nova/CoreTeam
where it says: A member of the team may be removed at any time by the PTL.
This is typically due to a drop off of involvement by the member such that
they are no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/05/2015 11:35 AM, Mikhail Fedosin wrote:
Yes, it's absolutely right. For example, Nova and Neutron have
official rules for that:
https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A
member of the team may be removed at any time by
-Original Message-
From: Flavio Percoco [mailto:fla...@redhat.com]
Sent: Wednesday, March 04, 2015 4:09 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
On 03/03/15 16:10 +, Nikhil Komawar
: Kuvaja, Erno kuv...@hp.com
Sent: Tuesday, March 3, 2015 9:48 AM
To: OpenStack Development Mailing List (not for usage questions); Daniel P.
Berrange
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
Nikhil,
If I recall correctly this matter was discussed last time
On Wed, Mar 04, 2015 at 07:38:42AM -0430, Flavio Percoco wrote:
I'm sorry but no. I don't think there's anything that requires extra
patience than 2 (or even more) cycles without provaiding reviews or
even any kind of active contribution.
I personally don't think adding new cores without
From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
Sent: Tuesday, March 03, 2015 4:10 PM
To: OpenStack Development Mailing List (not for usage questions); Daniel P.
Berrange
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
If it was not clear in my
kuv...@hp.com
Sent: Tuesday, March 3, 2015 9:48 AM
To: OpenStack Development Mailing List (not for usage questions); Daniel P.
Berrange
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
Nikhil,
If I recall correctly this matter was discussed last time at the start
From: Kuvaja, Erno kuv...@hp.com
Sent: Tuesday, March 3, 2015 9:48 AM
To: OpenStack Development Mailing List (not for usage questions); Daniel
P. Berrange
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
Nikhil,
If I recall correctly
Ian, thanks for raising the issue here.
The X-Forwarded headers are the standard way to deal with URLs for services
behind proxies. I already commented on the Heat proposal to that effect, I
think that is the proper way to support services behind proxies.
Now in our case, there is also another
...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
+1 on both proposals: rotation is definitely a step in right direction.
--
Regards,
Alexander Tivelkov
On Tue, Feb 24, 2015 at 1:19 PM, Daniel P. Berrange
berra...@redhat.commailto:berra...@redhat.com wrote:
On Tue, Feb 24
From: Alexander Tivelkov ativel...@mirantis.com
Sent: Tuesday, February 24, 2015 7:26 AM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage
questions)
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.
+1 on both
Hi Rob,
That is slightly different: from logical point of view that are
different schemas indeed, however they all map to the same DB schema,
so we do not have any issues with upgrades. There are some limitations
on the schema modifications as well, and being able to work with
multiple versions
On 13/02/15 17:01 +0100, Jordan Pittier wrote:
Humm this doesn't have to be complicated, for a start.
Sorry for my late reply
- Figuring out the http method the server expects (POST/PUT)
Yeah, I agree. Theres no definitive answer to this but I think PUT makes sense
here. I googled 'post vs
Jay, Flavio, thanks for this interesting discussion. I get your points and
they really make sense to me.
I'll go for a specific driver that will inherits from the HTTP Store for
the read path and implements the write path.
Jordan
On Tue, Feb 17, 2015 at 12:52 PM, Flavio Percoco
On 17 February 2015 at 03:31, Alexander Tivelkov ativel...@mirantis.com wrote:
Hi Client,
Thanks for your input.
We actually support the scenarios you speak about, yet in a slightly
different way. The authors of the Artifact Type (the plugin
developers) may define their own custom field
On 02/16/2015 01:39 PM, Jordan Pittier wrote:
So, I don't understand what allowing the HTTP backend to support add()
gives the user of Glance.
It doesn't give anything to the user.
glance_store is all about different backends, such as the VMWare
datastore or the Sheepdog data store. Having
So, I don't understand what allowing the HTTP backend to support add()
gives the user of Glance.
It doesn't give anything to the user.
glance_store is all about different backends, such as the VMWare datastore
or the Sheepdog data store. Having several backends/drivers allows the
cloud
Hi Ian,
On Tue, Feb 10, 2015 at 11:17 PM, Ian Cordasco
ian.corda...@rackspace.com wrote:
I think the fundamental disconnect is that not every column in a database
needs offer sorting to the user. Imposing that restriction here causes a
cascade of further restrictions that will fundamentally
Donald,
Thanks for your comments, really useful!
I think I need to clarify a bit: I am not speaking about the actual
semantic: placing the meaning into the actual values is still up to
the end-users (or the developers of Artifact Types, if they build some
custom logic which processes version
Hi Client,
Thanks for your input.
We actually support the scenarios you speak about, yet in a slightly
different way. The authors of the Artifact Type (the plugin
developers) may define their own custom field (or set of fields) to
store their sequence information or any other type-specific
On 12/02/15 09:34 -0800, Chris St. Pierre wrote:
Yeah, that commit definitely disables the file-backed queue -- it certainly
*looks* like we want to be rid of it, but all of the code is left in place and
even updated to support the new format. So my confusion remains. Hopefully Zhi
Yan can
Hi,
I believe that keeping review queue clean is the great idea.
But I am not sure that set of these rules is enough to abandon patches.
Recently I wrote blogpost related to making OpenStack community more user
friendly:
On 13/02/15 16:01 +0100, Jordan Pittier wrote:
What is the difference between just calling the Glance API to upload an image,
versus adding add() functionality to the HTTP image store?
You mean using glance image-create --location http://server1/myLinuxImage [..]
? If so, I guess adding the
On 13/02/15 11:06 +, Kuvaja, Erno wrote:
Hi all,
We have almost year old (from last update) reviews still in the queue for
glance. The discussion was initiated on yesterday’s meeting for adopting
abandon policy for stale changes.
The documentation can be found from
On 02/13/2015 09:47 AM, Jordan Pittier wrote:
Hi list,
I would like to add the 'add' capability to the HTTP glance store.
Let's say I (as an operator or cloud admin) provide an HTTP server where
(authenticated/trusted) users/clients can make the following HTTP request :
POST
to inactivity and indicates that the owner of that bug might
not be working on it after all.
- Erno
From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: Friday, February 13, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev
What is the difference between just calling the Glance API to upload an
image, versus adding add() functionality to the HTTP image store?
You mean using glance image-create --location http://server1/myLinuxImage
[..] ? If so, I guess adding the add() functionality will save the user
from having to
, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
from review
Hi,
I believe that keeping review queue clean is the great idea.
But I am not sure that set of these rules is enough to abandon
based on a missing
rebase.
Flavio
- Erno
From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: Friday, February 13, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
from
On 02/13/2015 10:01 AM, Jordan Pittier wrote:
What is the difference between just calling the Glance API to upload
an image, versus adding add() functionality to the HTTP image store?
You mean using glance image-create --location
http://server1/myLinuxImage [..] ? If so, I guess adding the
Hi,
Getting so mixed that I’ll jump to the inline commenting as well.
From: Boris Pavlovic [mailto:bo...@pavlovic.me]
Sent: 13 February 2015 15:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
from
Humm this doesn't have to be complicated, for a start.
- Figuring out the http method the server expects (POST/PUT)
Yeah, I agree. Theres no definitive answer to this but I think PUT makes
sense here. I googled 'post vs put' and I found that the idempotent and
who is in charge of the actual
Kuvaja, Erno kuv...@hp.com writes:
Hi all,
We have almost year old (from last update) reviews still in the queue
for glance. The discussion was initiated on yesterday's meeting for
adopting abandon policy for stale changes.
Hi,
Abandoning changes submitted by other people is not a good
Jay, I am afraid I didn't understand your point.
Could you rephrase/elaborate on What is the difference between just
calling the Glance API to upload an image, versus adding add() please ?
Currently, you can't call the Glance API to upload an image if the
default_store is the HTTP store.
On Fri,
-Original Message-
From: James E. Blair [mailto:cor...@inaugust.com]
Sent: 13 February 2015 16:44
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
from review
Kuvaja, Erno kuv...@hp.com
Erno Kuvaja wrote:
We have almost year old (from last update) reviews still in the queue
for glance. The discussion was initiated on yesterday's meeting for
adopting abandon policy for stale changes.
I'm okay with abandoning old some old reviews which are obviously going
nowhere, such as ones
On 02/13/2015 11:55 AM, Jordan Pittier wrote:
Jay, I am afraid I didn't understand your point.
Could you rephrase/elaborate on What is the difference between just
calling the Glance API to upload an image, versus adding add() please ?
Currently, you can't call the Glance API to upload an image
On 13/02/15 16:22 -0800, Chris St. Pierre wrote:
That's good to know, but I'm still just the weensiest bit confused. The code is
unreachable and unusable -- which is a bit more forceful than just redundant or
deprecated. Can it be removed? Does Zhi Yan have plans to do that? Is there
anything I
That's good to know, but I'm still just the weensiest bit confused. The
code is unreachable and unusable -- which is a bit more forceful than just
redundant or deprecated. Can it be removed? Does Zhi Yan have plans to do
that? Is there anything I can do to help?
Thanks!
On Fri, Feb 13, 2015 at
On 2/11/15, 11:10, Okuma, Wayne wayne.ok...@hp.com wrote:
Hello,
I would like to change the metadef-tags create API which was checked into
Kilo (cycle 1).
The python-glanceclient that would support metadef-tags has not been
released yet and I would like to make this change before doing so.
The
On 2/12/15, 9:57 AM, Ian Cordasco ian.corda...@rackspace.com wrote:
On 2/11/15, 11:10, Okuma, Wayne wayne.ok...@hp.com wrote:
Hello,
I would like to change the metadef-tags create API which was checked into
Kilo (cycle 1).
The python-glanceclient that would support metadef-tags has not been
On 11/02/15 13:42 -0800, Chris St. Pierre wrote:
I recently proposed a change to glance to turn the file-backed scrubber queue
files into JSON: https://review.openstack.org/#/c/145223/
As I looked into it more, though, it turns out that the file-backed queue is no
longer usable; it was killed
Yeah, that commit definitely disables the file-backed queue -- it certainly
*looks* like we want to be rid of it, but all of the code is left in place
and even updated to support the new format. So my confusion remains.
Hopefully Zhi Yan can clarify.
Link added. Thanks.
On Thu, Feb 12, 2015 at
Hello,
I would like to change the metadef-tags create API which was checked into Kilo
(cycle 1).
The python-glanceclient that would support metadef-tags has not been released
yet and I would like to make this change before doing so.
The details are here: https://review.openstack.org/#/c/154229/
On 02/10/2015 10:28 AM, Alexander Tivelkov wrote:
Hi folks,
One of the key features that we are adding to Glance with the
introduction of Artifacts is the ability to have multiple versions of
the same object in the repository: this gives us the possibility to
query for the latest version of
Hi Ian,
Automatic version generation is not the only and not the primary
reason for the version concept. In fact, the implementation which is
planned to land in this cycle does not contain this feature at all:
currently we also leave the version assignment up to uploader (version
is a regular
Thanks Monty!
Yup, probably I've missed that. I was looking at pbr and its version
implementation, but didn't realize that this is actually a fusion of
semver and pep440.
So, we have this as an extra alternative to choose from.
It would be an obvious choice if we were just looking for some
On 2/10/15, 10:35, Alexander Tivelkov ativel...@mirantis.com wrote:
Thanks Monty!
Yup, probably I've missed that. I was looking at pbr and its version
implementation, but didn't realize that this is actually a fusion of
semver and pep440.
So, we have this as an extra alternative to choose
On Feb 10, 2015, at 3:17 PM, Ian Cordasco ian.corda...@rackspace.com wrote:
And of course, the chosen solution should be mappable to database, so
we may do sorting and filtering on the DB-side.
So, having it as a simple string and letting the user to decide what
it means is not an
I agree with Alexander on this. We should certainly learn what we can from
existing software. That said, the Solum team really wants this feature in
Glance so we can leverage that instead of having our own repository for Heat
templates we generate when building apps. We want to keep our
On 2/10/15, 12:01, Alexander Tivelkov ativel...@mirantis.com wrote:
Hi Ian,
Automatic version generation is not the only and not the primary
reason for the version concept. In fact, the implementation which is
planned to land in this cycle does not contain this feature at all:
currently we also
On 2/10/15, 13:55, Jay Pipes jaypi...@gmail.com wrote:
On 02/10/2015 12:15 PM, Ian Cordasco wrote:
So Semantic Versioning, as I’ve already mentioned in the past, isn’t
really a de facto standard in any language community but it is a
language
agnostic proposal. That said, just because it’s
Excerpts from Alexander Tivelkov's message of 2015-02-10 07:28:55 -0800:
Hi folks,
One of the key features that we are adding to Glance with the
introduction of Artifacts is the ability to have multiple versions of
the same object in the repository: this gives us the possibility to
query
On 1/15/15 12:59 AM, Flavio Percoco wrote:
All that being said, it'd be very nice if you could open a spec on
this topic so we can discuss over the spec review and one of us (or
you) can implement it if we reach consensus.
I'll create a BP + spec; doing a little homework now...
W / R / T
, January 19, 2015 9:39 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Replication on image create
On 1/15/15 12:59 AM, Flavio Percoco wrote:
All that being said, it'd be very nice if you could open a spec on
this topic so we can discuss over the spec review and one
...@gmail.com]
Sent: Wednesday, January 14, 2015 10:25 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Replication on image create
On 01/13/2015 04:55 PM, Boden Russell wrote:
Looking for some feedback from the glance dev team on a potential BP…
The use case I’m trying
On 13/01/2015 3:45 AM, Jeremy Stanley fu...@yuggoth.org wrote:
There's really no way to _force_ official logging on all
project-related channels. People who are opposed to the idea simply
move their conversations to new channels. They'll straddle the line
between somewhat official looking and
On 14/01/15 05:46 -0700, Boden Russell wrote:
On 1/14/15 1:38 AM, Flavio Percoco wrote:
On 13/01/15 21:24 -0500, Jay Pipes wrote:
On 01/13/2015 04:55 PM, Boden Russell wrote:
Looking for some feedback from the glance dev team on a potential BP…
This is the solution that I would recommend.
-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] Replication on image create
On 01/13/2015 04:55 PM, Boden Russell wrote:
Looking for some feedback from the glance dev team on a potential BP…
The use case I’m trying to solve is —
As an admin, I want my glance image bits replicated
801 - 900 of 1327 matches
Mail list logo
