Re: [openstack-dev] [k8s] OpenStack and Containers White Paper

[Mikhail Fedosin]

Hello!
I'm working on Keystone authentication and authorization and other related
parts of openstack cloud provider. I will be happy to help you!

Best,
Mike

On Tue, Apr 3, 2018 at 8:38 AM, Jaesuk Ahn  wrote:

> Hi Chris,
>
> I can probably help on proof-reading and making some contents on the
> openstack-helm part.
> As Pete pointed out, LOCI and OpenStack-Helm (OSH) are agnostic to each
> other. OSH is working well with both kolla image and loci image.
>
> IMHO, following categorization might be better to capture the nature of
> these project. Just suggestion.
>
> * OpenStack Containerization tools
>* Kolla
>* Loci
> * Container-based deployment tools for installing and managing OpenStack
>* Kolla-Ansible
>* OpenStack Helm
>
>
> On Tue, Apr 3, 2018 at 10:08 AM Pete Birley  wrote:
>
>> Chris,
>>
>> I'd be happy to help out where I can, mostly related to OSH and LOCI. One
>> thing we should make clear is that both of these projects are agnostic to
>> each other: we gate OSH with both LOCI and kolla images, and conversely
>> LOCI has uses far beyond just OSH.
>>
>> Pete
>>
>> On Monday, April 2, 2018, Chris Hoge  wrote:
>>
>>> Hi everyone,
>>>
>>> In advance of the Vancouver Summit, I'm leading an effort to publish a
>>> community produced white-paper on OpenStack and container integrations.
>>> This has come out of a need to develop materials, both short and long
>>> form, to help explain how OpenStack interacts with container
>>> technologies across the entire stack, from infrastructure to
>>> application. The rough outline of the white-paper proposes an entire
>>> technology stack and discuss deployment and usage strategies at every
>>> level. The white-paper will focus on existing technologies, and how they
>>> are being used in production today across our community. Beginning at
>>> the hardware layer, we have the following outline (which may be inverted
>>> for clarity):
>>>
>>> * OpenStack Ironic for managing bare metal deployments.
>>> * Container-based deployment tools for installing and managing OpenStack
>>>* Kolla containers and Kolla-Ansible
>>>* Loci containers and OpenStack Helm
>>> * OpenStack-hosted APIs for managing container application
>>>   infrastructure.
>>>* Magnum
>>>* Zun
>>> * Community-driven integration of Kubernetes and OpenStack with K8s
>>>   Cloud Provider OpenStack
>>> * Projects that can stand alone in integrations with Kubernetes and
>>>   other cloud technology
>>>* Cinder
>>>* Neutron with Kuryr and Calico integrations
>>>* Keystone authentication and authorization
>>>
>>> I'm looking for volunteers to help produce the content for these sections
>>> (and any others we may uncover to be useful) for presenting a complete
>>> picture of OpenStack and container integrations. If you're involved with
>>> one of these projects, or are using any of these tools in
>>> production, it would be fantastic to get your input in producing the
>>> appropriate section. We especially want real-world deployments to use as
>>> small case studies to inform the work.
>>>
>>> During the process of creating the white-paper, we will be working with a
>>> technical writer and the Foundation design team to produce a document
>>> that
>>> is consistent in voice, has accurate and informative graphics that
>>> can be used to illustrate the major points and themes of the white-paper,
>>> and that can be used as stand-alone media for conferences and
>>> presentations.
>>>
>>> Over the next week, I'll be reaching out to individuals and inviting them
>>> to collaborate. This is also a general invitation to collaborate, and if
>>> you'd like to help out with a section please reach out to me here, on the
>>> K8s #sig-openstack Slack channel, or at my work e-mail,
>>> ch...@openstack.org.
>>> Starting next week, we'll work out a schedule for producing and
>>> delivering
>>> the white-paper by the Vancouver Summit. We are very short on time, so
>>> we will have to be focused to quickly produce high-quality content.
>>>
>>> Thanks in advance to everyone who participates in writing this
>>> document. I'm looking forward to working with you in the coming weeks to
>>> publish this important resource for clearly describing the multitude of
>>> interactions between these complementary technologies.
>>>
>>> -Chris Hoge
>>> K8s-SIG-OpenStack/OpenStack-SIG-K8s Co-Lead
>>>
>>>
>>> 
>>> __
>>> 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
>>>
>>
>>
>> --
>>
>> [image: Port.direct] 
>>
>> Pete Birley / Director
>> pete@port.direct / +447446862551 <+44%207446%20862551>
>>
>> *PORT.*DIRECT
>> United Kingdom
>> https://port.direct
>>
>> This e-mail message may 

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Hello!

I created an etherpad with the topics I want to discuss:
https://etherpad.openstack.org/p/ptg-glare-etsi

There I want to make a brief overview of glare features, that may be useful
for vnf packages support, and get a list of requirements from ETSI NFV
delegates, they want to see in the catalog of VNF packages.

Best regards,
Mikhail Fedosin

On Tue, Sep 5, 2017 at 6:04 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
>
>
> We can try to squeeze it into the schedule. Can you collect your
> discussion topics to an etherpad so we can decide on the timing of the
> timeslot?
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Tuesday, September 5, 2017 3:46 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Yes, It will be even better! I can record a demo and publish it before the
> meeting.
>
>
>
> Could you schedule a short talk about IFA007 during the workshop?
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
>
>
> Thanks for the proposal. The aim of this workshop is to accelerate the
> collaboration between OpenStack and ETSI and not to execute demonstrations.
> However if you have technical questions to IFA about IFA007 then we can add
> that as an agenda point.
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Friday, September 1, 2017 1:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Hello!
>
>
>
> I would also like to discuss the possibility of using Glare for
> cataloging VNF packages. Generally speaking Glare satisfies all the
> requirements from the standard http://www.etsi.org/
> deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
>
> Could we include this topic in the discussions, too?
>
>
>
> I plan to create an artifact type and present a short demo there, about
> how glare can work with the packages. If this topic is interesting, then we
> can discuss it in more detail on Wednesday or Thursday in dedicated Glare
> team room.
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> 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:unsubs

Re: [openstack-dev] [glance] multi threads with swift backend

[Mikhail Fedosin]

Hey! As you said it's not possible now.

I implemented the support several years ago, bit unfortunately no one
wanted to review it: https://review.openstack.org/#/c/218993
If you want, we can revive it.

Best,
Mike

On Wed, Sep 6, 2017 at 9:05 PM, Clay Gerrard  wrote:

> I'm pretty sure that would only be possible with a code change in glance
> to move the consumption of the swiftclient abstraction up a layer from the
> client/connection objects to swiftclient's service objects [1].  I'm not
> sure if that'd be something that would make a lot of sense to the Image
> Service team.
>
> -Clay
>
> 1. https://docs.openstack.org/python-swiftclient/latest/service-api.html
>
> On Wed, Sep 6, 2017 at 9:02 AM, Arnaud MORIN 
> wrote:
>
>> Hi all,
>>
>> Is there any chance that glance can use the multiprocessing from
>> swiftclient library (equivalent of xxx-threads options from cli)?
>> If yes, how to enable it?
>> I did not find anything useful in the glance configuration options.
>> And looking at glance_store code make me think that it's not possible...
>> Am I wrong?
>>
>> Regards,
>> Arnaud
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Yes, It will be even better! I can record a demo and publish it before the
meeting.

Could you schedule a short talk about IFA007 during the workshop?

Best regards,
Mikhail Fedosin

On Fri, Sep 1, 2017 at 5:30 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
>
>
> Thanks for the proposal. The aim of this workshop is to accelerate the
> collaboration between OpenStack and ETSI and not to execute demonstrations.
> However if you have technical questions to IFA about IFA007 then we can add
> that as an agenda point.
>
>
>
> Br,
>
> Gerg0
>
>
>
> *From:* Mikhail Fedosin [mailto:mfedo...@gmail.com]
> *Sent:* Friday, September 1, 2017 1:03 PM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
>
> *Subject:* Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
>
> Hello!
>
>
>
> I would also like to discuss the possibility of using Glare for
> cataloging VNF packages. Generally speaking Glare satisfies all the
> requirements from the standard http://www.etsi.org/
> deliver/etsi_gs/NFV-IFA/001_099/007/02.01.01_60/gs_NFV-IFA007v020101p.pdf
>
> Could we include this topic in the discussions, too?
>
>
>
> I plan to create an artifact type and present a short demo there, about
> how glare can work with the packages. If this topic is interesting, then we
> can discuss it in more detail on Wednesday or Thursday in dedicated Glare
> team room.
>
>
>
> Best regards,
>
> Mikhail Fedosin
>
>
>
> On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
> gergely.csat...@nokia.com> wrote:
>
> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> 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

Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]: OpenStack meets ETSI NFV workshop on 12.09.2017

[Mikhail Fedosin]

Hello!

I would also like to discuss the possibility of using Glare for cataloging
VNF packages. Generally speaking Glare satisfies all the requirements from
the standard http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/007/
02.01.01_60/gs_NFV-IFA007v020101p.pdf
Could we include this topic in the discussions, too?

I plan to create an artifact type and present a short demo there, about how
glare can work with the packages. If this topic is interesting, then we can
discuss it in more detail on Wednesday or Thursday in dedicated Glare team
room.

Best regards,
Mikhail Fedosin

On Mon, Aug 28, 2017 at 5:06 PM, Csatari, Gergely (Nokia - HU/Budapest) <
gergely.csat...@nokia.com> wrote:

> Hi,
>
> Thanks for the clarification.
>
> Our understanding was that with Panko it is possible to subscribe to the
> state of the different resource of the cloud as it is descibed in [1]. This
> is why we mapped the Virtualised [Compute|Network|Storage] Resources
> Capacity Management Interfaces to Panko.
>
> [1]: https://wiki.openstack.org/wiki/Telemetry#Managed
>
> Br,
> Gerg0
>
>
> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, August 28, 2017 3:05 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][nova][neutron][qa][panko][blazar]:
> OpenStack meets ETSI NFV workshop on 12.09.2017
>
>
> > Gaps to be discussed are here:
> > https://etherpad.openstack.org/p/ptg-denver-etsi-nfv-tst003-gaps-expla
> > ined
>
> i added a note in etherpad but it seems you want Ceilometer (+Gnocchi if
> you need storagE) and not Panko. Panko only handles storage of events (more
> metadata focused data) while Ceilometer handles the actual generation of
> both events and metrics, the latter being the one you want it seems.
> Gnocchi is used for optimised time-series metric storage.
>
> unfortunately, i don't believe anyone from Telemetry teams are attending
> the PTG but we can be reached on ML or #openstack-telemetry.
>
> cheers,
>
> --
> gord
> __
> 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-dev] [Glare] Application for inclusion of Glare in the list of official projects - Answers

[Mikhail Fedosin]

Hello! Thank you all for your answers and advises!

I will try to summarize all of the above.

The purpose of the application was to get the community's views on
including Glare in the list of official projects, and a potential
replacement of Glance in the foreseeable future. A large number of
inspirational mails were received, and there were a number of questions
that I should answer.

1. "Glare is being developed by one company and a very limited circle of
people."
At this stage this is undoubtedly so. But I think this is more a plus
than a minus. Working out in a small team allows us to move much faster,
and do not spend months discussing simple things. Also I want to note that
three full-time engineers is enough. Obviously, this will not always be the
same. When we give the project to the community (i.e. make it an official
project), I can guarantee that the distribution by companies will increase.

2. "Glance is used everywhere, Glare will be very hard to replace him."
Well, no one said that it would be easy. For our part, we did our best
to simplify this transition as much as possible: the data of Glance can be
migrated to Glare by a simple script, Glare API is a cleaned and improved
version of the Glance v2 API (
https://docs.google.com/document/d/18Tqad0NUPyFfHUo1KMr6bDDISpQtzacvZtEQIGhNkf4/edit?usp=sharing).
>From my experience I can say that the transition from Glance v1 to Glance
v2 was at times more painful than this.

3. "What are the pros / cons of the transition to Glare"
I'll start with the pros:
OpenStack will get the features that the customers wanted from us
for several years: dynamic quotas that determine how much data a particular
tenant can upload, versioning of artifacts, support for layers, which will
make a universal COW in Cinder regardless of the proposed backend, and many
others, including missing "copy-from" from Glance v1.
Glare is much stabler by design. There are no race conditions
(artifacts are locked before updates), all the known problems of Glance
were also solved in Glare.
Subjectively, but it seems to me that the Glare code is better and
the architecture is cleaner. This will allow people unfamiliar with the
project to adapt more quickly to it.
Cons:
Glance was developed long enough and it has good documentation,
also there are many tests. In other words, the project has been studied,
which can not be said about Glare. According to my feelings after the
transfer of the project, we will need a year's minimum for its adaptation
in the industry.
It will take some effort to move from one project to another in
existing clouds. I believe that this process can be automated, but at the
same time I understand the complexity of such operations.

4. "How can a transition be made".
I have several ideas how to organize this. But still I believe that the
decision should be taken by all together after a series of discussions. In
the basic version, I see it like this:
1. We create an adapter in glare client that hides the minimal
differences between Glance v2 and Glare v1 APIs. For example, the image
will be activated immediately after upload.
2. In Nova, another glare.py module will be created, which in fact
is just a copy of glance.py with cosmetic changes.
3. Existing data migrate without loss by a simple script.
4. ?
5. PROFIT!

5. "There's enough overlap between glare and glance + barbican + swift"
I do not think there are any overlapping with Barbican and Swift. Swift
is used as one of the possible backends (as in Glance), Glare only stores
links to the data in it.
Like in Barbican there is a potential opportunity to keep secrets in
Glare. This logic can be added with just one plugin. But in order to avoid
potential collisions, it was decided not to include this plugin in the
official repository, since it has not yet been properly tested.

6. "Is there any documentation to familiarize with the project closer"
Yes, there is documentation, but it obviously is not enough. Here are
the main links:
Glare repo: https://github.com/openstack/glare
Glare client repo: https://github.com/openstack/python-glareclient

How to deploy Glare in Docker:
https://github.com/Fedosin/docker-glare

How to deploy Glare in Devstack:
https://github.com/openstack/glare/tree/master/devstack

Glare API description:
https://github.com/openstack/glare/blob/master/doc/source/developer/webapi/v1.rst

Glare architecture description:
https://github.com/openstack/glare/blob/master/doc/source/architecture.rst

Set of glare demos (slightly outdated):
  Glare artifact lifecycle: https://asciinema.org/a/97985
  Listing of artifacts in Glare: https://asciinema.org/a/97986
  Creating a new artifact type: https://asciinema.org/a/97987
  Locations, Tags, Links and Folders: https://asciinema.org/a/99771

Now I'm 

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 1:43 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 07/10/2017 04:31 PM, Mikhail Fedosin wrote:
>
>> Thank you for asking this! It's really very important and interesting, so
>> I'm going to explain those things more detailed.
>>
>> First, when we designed Glare, we kept in mind the compatibility with
>> Glance, and I can tell that Glance data from the database can be ported to
>> Glare with a simple script without any loss.
>>
>> Second, APIs are very similar and map 1:1. The only one big difference is
>> that user has to perform activation manually after image file is uploaded.
>> I created a small table with the most popular API requests. You may notice
>> how similar both APIs are: https://docs.google.com/docume
>> nt/d/18Tqad0NUPyFfHUo1KMr6bDDISpQtzacvZtEQIGhNkf4/edit?usp=sharing
>> Other changes are rather cosmetic. For instance, "queued" image status
>> was renamed to "drafted".
>>
>> Third, all these changes can be hidden in Glare client. So if we try a
>> little, we can achieve 100% compatibility there, and other projects can use
>> Glare client instead of Glance's without even noticing the differences.
>>
>
> I think we should definitely not do this... I think instead, if we decide
> to go down this road, we want to look at adding an endpoint to glare that
> speaks glance v2 API so that users can have a transition period while
> libraries and tools get updated to understand the artifacts API.


This is optional and depends on the project developers. For my part, I can
only offer the most compatible client, so that the Glance module can be
simply copied into the new Glare module.


>
> If projects use Glance without client, it means that some direct API
>> requests will need to be rewritten. But in any case, the number of
>> differences between Glance v1 and Glance v2 was much larger, and we
>> switched pretty smoothly. So I hope everything will be fine here, too.
>>
>
> v1 vs v2 is still a major headache for end users. I don't think it's ok
> for us to do that to our users again if we can help it.
>
> However, as you said, conceptually the calls are very similar so making an
> API controller that can be registered in the catalog as "image" should be
> fairly easy to do, no?
>
Indeed, the interfaces are almost identical. And all the differences were
made on purpose.

For example, deactivating an image in Glance looks like *POST*
/v2/images/{image_id}/actions/deactivate with empty body.
At one time, Chris Dent advised us to avoid such decisions, and simply
change the status of the artifact to 'deactivated' using *PATCH*, which we
did.

>
> Best,
>> Mike Fedosin
>>
>> On Mon, Jul 10, 2017 at 9:55 PM, Joshua Harlow <harlo...@fastmail.com
>> <mailto:harlo...@fastmail.com>> wrote:
>>
>> Ed Leafe wrote:
>>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com
>> <mailto:mfedo...@gmail.com>
>> <mailto:mfedo...@gmail.com <mailto:mfedo...@gmail.com>>> wrote:
>>
>> Given all the advantages and features of Glare, I believe
>> that it can
>> become the successful drop-in replacement.
>>
>>
>> Can you clarify this? Let’s assume I have a decent-sized
>> deployment
>> running Glance. If I were to remove Glance and replace it with
>> Glare,
>> are you saying that nothing would break? Operators, users,
>> scripts,
>> SDKs, etc., would all work unchanged?
>>
>>
>> Sounds interesting,
>>
>> Is there some kind of glance-compat API?
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://openstack-dev-requ...@lists.openstack.org?subject:un
>> subscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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://openstack-dev-requ...@lists.openstack.org?sub

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 12:31 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 07/10/2017 01:21 PM, Ed Leafe wrote:
>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com > mfedo...@gmail.com>> wrote:
>>
>> Given all the advantages and features of Glare, I believe that it can
>>> become the successful drop-in replacement.
>>>
>>
>> Can you clarify this? Let’s assume I have a decent-sized deployment
>> running Glance. If I were to remove Glance and replace it with Glare, are
>> you saying that nothing would break? Operators, users, scripts, SDKs, etc.,
>> would all work unchanged?
>>
>
> I also have this question. The glance API is one of the most fundamental
> and basic APIs. You pretty much can't do anything useful on a cloud without
> touching it.
>
> That said - it's not like glare couldn't also do those things - but I'd
> need to understand some real specifics about what a cloud switching from
> glance to glare looks like to the end user.
>
> Also, we have a new upload API designed for glance that took a LARGE
> amount of wrangling to get consensus on. I'd also want to know what this
> situation looks like in glare, if image upload in glare supports all of the
> use-cases that we figured out image upload in glance needed to support. AND
> - there are folks who want import-from which was removed between glance v1
> and v2. Does glare support something in this area?


I think you ask about "copy-from". Then yes, it's planned to implement this
week.


>
>
> __
> 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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

On Tue, Jul 11, 2017 at 12:54 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 07/10/2017 04:31 PM, Monty Taylor wrote:
>
>> On 07/10/2017 01:21 PM, Ed Leafe wrote:
>>
>>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com
>>> <mailto:mfedo...@gmail.com>> wrote:
>>>
>>> Given all the advantages and features of Glare, I believe that it can
>>>> become the successful drop-in replacement.
>>>>
>>>
>>> Can you clarify this? Let’s assume I have a decent-sized deployment
>>> running Glance. If I were to remove Glance and replace it with Glare, are
>>> you saying that nothing would break? Operators, users, scripts, SDKs, etc.,
>>> would all work unchanged?
>>>
>>
>> I also have this question. The glance API is one of the most fundamental
>> and basic APIs. You pretty much can't do anything useful on a cloud without
>> touching it.
>>
>
> Actually - as an easy first-step - set up a gate job with a devstack that
> has glare and no glance and run shade's functional tests against it. We're
> pretty darned lenient - if you can pass our functional tests then talking
> about stricter things like tempest is worthwhile. If you can't - hopefully
> there will be some clear areas to work on.

Yes again - creating a set of tempest gates in jenkins is our highest
priority. If everything is fine, I'll propose related patches today.


>
>
> That said - it's not like glare couldn't also do those things - but I'd
>> need to understand some real specifics about what a cloud switching from
>> glance to glare looks like to the end user.
>>
>> Also, we have a new upload API designed for glance that took a LARGE
>> amount of wrangling to get consensus on. I'd also want to know what this
>> situation looks like in glare, if image upload in glare supports all of the
>> use-cases that we figured out image upload in glance needed to support. AND
>> - there are folks who want import-from which was removed between glance v1
>> and v2. Does glare support something in this area?
>>
>
>
>
> __
> 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

Re: [openstack-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

Thank you for asking this! It's really very important and interesting, so
I'm going to explain those things more detailed.

First, when we designed Glare, we kept in mind the compatibility with
Glance, and I can tell that Glance data from the database can be ported to
Glare with a simple script without any loss.

Second, APIs are very similar and map 1:1. The only one big difference is
that user has to perform activation manually after image file is uploaded.
I created a small table with the most popular API requests. You may notice
how similar both APIs are:
https://docs.google.com/document/d/18Tqad0NUPyFfHUo1KMr6bDDISpQtzacvZtEQIGhNkf4/edit?usp=sharing
Other changes are rather cosmetic. For instance, "queued" image status was
renamed to "drafted".

Third, all these changes can be hidden in Glare client. So if we try a
little, we can achieve 100% compatibility there, and other projects can use
Glare client instead of Glance's without even noticing the differences.

If projects use Glance without client, it means that some direct API
requests will need to be rewritten. But in any case, the number of
differences between Glance v1 and Glance v2 was much larger, and we
switched pretty smoothly. So I hope everything will be fine here, too.

Best,
Mike Fedosin

On Mon, Jul 10, 2017 at 9:55 PM, Joshua Harlow <harlo...@fastmail.com>
wrote:

> Ed Leafe wrote:
>
>> On Jul 10, 2017, at 5:06 AM, Mikhail Fedosin <mfedo...@gmail.com
>> <mailto:mfedo...@gmail.com>> wrote:
>>
>> Given all the advantages and features of Glare, I believe that it can
>>> become the successful drop-in replacement.
>>>
>>
>> Can you clarify this? Let’s assume I have a decent-sized deployment
>> running Glance. If I were to remove Glance and replace it with Glare,
>> are you saying that nothing would break? Operators, users, scripts,
>> SDKs, etc., would all work unchanged?
>>
>
> Sounds interesting,
>
> Is there some kind of glance-compat API?
>
>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-dev] [Glare][TC] Application for inclusion of Glare in the list of official projects

[Mikhail Fedosin]

Hello!

Recently I applied for inclusion of Glare in the list of official OpenStack
projects: https://review.openstack.org/#/c/479285/ In this regard, I would
like to ask the community what other things can be improved in the project
to meet all the necessary requirements.

Also in this thread I would like to discuss the role of the project in
OpenStack. Lately opinions have been increasingly expressed that Glance no
longer meets the current needs of OpenStack and should be replaced in the
foreseeable future.  And as you know, initially Glare was designed as a new
improved version of Glance, which works with all types of data, not just
with virtual machine images. Given all the advantages and features of
Glare, I believe that it can become the successful drop-in replacement.
Glare already has parity in terms of features with Glance and can be used
by Nova as a means for storing images. In addition to this we are
developing a number of other interesting things that will help many
projects to store their data in a convenient and reliable way. Therefore, I
propose to transfer Glance to the status of stable and supported project
starting from the next cycle, and to declare Glare as a new version in the
medium term.

In the end I would like to ask about PTG - I would be happy to present
Glare at one or two sessions in Denver, if I get this opportunity.

Thank you in advance for your comments!

Best,
Mike Fedosin
__
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] [Glare][TC][All] Past, Present and Future of Glare project

[Mikhail Fedosin]

On Tue, Jun 27, 2017 at 10:19 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 26/06/17 17:35 +0300, Mikhail Fedosin wrote:
>
>> 2. We would like to become an official OpenStack project, and in general
>> we
>> follow all the necessary rules and recommendations, starting from weekly
>> IRC meetings and our own channel, to Apache license and Keystone support.
>> For this reason, I want to file an application and hear objections and
>> recommendations on this matter.
>>
>
> Note that IRC meetings are not a requirement anymore:
> https://review.openstack.org/#/c/462077/
>
> As far as the rest of the process goes, it looks like you are all good to
> go.
> I'd recommend you to submit the request to the governance repo and let the
> discussion begin: https://governance.openstack.o
> rg/tc/reference/new-projects-requirements.html
>
> Flavio
>

Thank you Flavio - it's exactly what I suppose to do!

>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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

Re: [openstack-dev] [Glare][TC][All] Past, Present and Future of Glare project

[Mikhail Fedosin]

On Tue, Jun 27, 2017 at 3:33 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> From what I can tell, Keycloak is an Identity provider, not a secret store?
>
> Yes! I should explain more detailed.

CloudBand is a big enterprise system for SDN and OpenStack is a part of it.
The default Identity provider of the system is Keycloak.
Currently Glare is used there not as a part of OpenStack deployment, but as
a standalone service outside of OpenStack.
For this reason earlier this year we implemented Keycloak auth middleware
for the server and authentication mechanism in the client,
i.e. we can use Keycloak instead of Keystone.

The decision regarding the secrets was taken, on the grounds that Barbican
does not have such ability, and it's tightly attached
to Keystone. Moreover it was not difficult to implement the plugin for
Glare.
As I said - originally this is a private plugin, which was decided to
opensource for the OpenStack community. If this is not required, then
we can always cancel it. I don't see any problems with this.


> -jay
>
> On 06/27/2017 05:35 AM, Adam Heczko wrote:
>
>> Barbican already supports multiple secret storage backends [1] and most
>> likely adding Keycloak's one [2] should be possible.
>>
>> [1] https://docs.openstack.org/project-install-guide/key-manager
>> /draft/barbican-backend.html
>> [2] https://github.com/jpkrohling/secret-store
>>
>> On Tue, Jun 27, 2017 at 10:42 AM, Thierry Carrez <thie...@openstack.org
>> <mailto:thie...@openstack.org>> wrote:
>>
>> Mikhail Fedosin wrote:
>> > Does the above mean you are implementing a share secret
>> storage
>> > solution or that you are going to use an existing
>> solution like
>> > Barbican that does that?
>> >
>> > Sectets is a plugin for Glare we developed for Nokia
>> CloudBand
>> > platform,   and they just decided to opensource it. It
>> doesn't
>> > use Barbican, technically it is oslo.versionedobjects class.
>> >
>> > Sorry to hear that you opted not to use Barbican.
>> >
>> > I think it's only because Keycloak integration is required by
>> Nokia's
>> > system and Barbican doesn't support it.
>>
>> Any technical reason why it couldn't be added to Barbican ? Any chance
>> Keycloak integration could be added as a Castellan backend ? Secrets
>> management is really one of those things that should *not* be
>> reinvented
>> in every project. It is easier to get wrong than people think, and you
>> end up having to do security audits on 10 repositories instead of one.
>>
>> --
>> Thierry Carrez (ttx)
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> 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
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>
>>
>>
>>
>> --
>> Adam Heczko
>> Security Engineer @ Mirantis Inc.
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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

Re: [openstack-dev] [Glare][TC][All] Past, Present and Future of Glare project

[Mikhail Fedosin]

On Jun 26, 2017 7:14 PM, "Jay Pipes" <jaypi...@gmail.com> wrote:

On 06/26/2017 11:32 AM, Mikhail Fedosin wrote:


>
> On Jun 26, 2017 5:54 PM, "Jay Pipes" <jaypi...@gmail.com  jaypi...@gmail.com>> wrote:
>
> On 06/26/2017 10:35 AM, Mikhail Fedosin wrote:
>
> * Storage of secrets - a new artifact type in Glare, which
> will store private information (keys, passwords, etc.) in an
> encrypted form (like in Barbican).
>
>
> Does the above mean you are implementing a share secret storage
> solution or that you are going to use an existing solution like
> Barbican that does that?
>
> Sectets is a plugin for Glare we developed for Nokia CloudBand platform,
>  and they just decided to opensource it. It doesn't use Barbican,
> technically it is oslo.versionedobjects class.
>

Sorry to hear that you opted not to use Barbican.

I think it's only because Keycloak integration is required by Nokia's
system and Barbican doesn't support it.


But, I'm confused what oslo.versionedobjects has to do with secrets
storage. Could you explain?

Oslo.versionedobjects just defines a structure of artifact type. But we
also implemented two new field types for oslo_vo - Blob and Folder, which
can be used similar to Integer or String.

When user tries to write data to a Blob field it is automatically decoded
and uploaded to a cloud store by glance_store library. And vice versa -
when user reads data from the Blob field it is dowloaded from the store and
decoded.

So, consider Glare as a synergy of glance_store and oslo.versionedobjects
with RESTful API above it.



Best,
-jay

__
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

Re: [openstack-dev] [Glare][TC][All] Past, Present and Future of Glare project

[Mikhail Fedosin]

On Jun 26, 2017 5:54 PM, "Jay Pipes" <jaypi...@gmail.com> wrote:

On 06/26/2017 10:35 AM, Mikhail Fedosin wrote:

>* Storage of secrets - a new artifact type in Glare, which will store
> private information (keys, passwords, etc.) in an encrypted form (like in
> Barbican).
>

Does the above mean you are implementing a share secret storage solution or
that you are going to use an existing solution like Barbican that does that?

Sectets is a plugin for Glare we developed for Nokia CloudBand platform,
 and they just decided to opensource it. It doesn't use Barbican,
technically it is oslo.versionedobjects class.


Best,
-jay

__
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] [Glare][TC][All] Past, Present and Future of Glare project

[Mikhail Fedosin]

Hello! It's me again. I hasten to inform you about the latest news in Glare
project!

To begin with, I want to say that:

First, we created the stable branch (stable/ocata), which is already used
in production. This is undoubtedly a joyful event and the result of long
months of work!
Secondly, we are adding integration with the Mistral:
https://review.openstack.org/#/c/473898/
Third, we moved on to the active implementation of new features. In
general, I promised them for a long time already, but we decided to devote
the last few months to stabilize the project and make it good for
production. The next big release is scheduled for late August, and there we
will add:
  * ACLs aka sharing of artifacts, where tenants can share their artifacts
with the other.
  * Dynamic quotas, when the operator can choose how much data for what
type a particular tenant can upload (for instance, Anna can upload 1 Tb of
images and 100Mb of heat templates; Betty can upload 500Gb of images and
50Mb of heat templates, and so on)
  * Asynchronous data processing, which can be used for background
conversion and validation of large amounts of data on the server side.
  * Storage of secrets - a new artifact type in Glare, which will store
private information (keys, passwords, etc.) in an encrypted form (like in
Barbican).

Now I want to discuss a few questions with OpenStack community and get some
opinions.

1. Generally speaking, I want to make the development of Glare more open
and create a community around the project. Now the development of Glare
engaged in two full-time engineers from Nokia plus me. But as you can see
we have a large list of tasks, and we will gladly accept more people.
Perhaps someone from Glance, Nova or Cinder projects will want to
participate in the development.

2. We would like to become an official OpenStack project, and in general we
follow all the necessary rules and recommendations, starting from weekly
IRC meetings and our own channel, to Apache license and Keystone support.
For this reason, I want to file an application and hear objections and
recommendations on this matter.

3. Finally, I want to discuss the future of the project and its role in
OpenStack. As has been noted many times, the project is capable of much
more, and we only need to find the right application for it. I believe that
this issue will be conceptually discussed in Denver, but nevertheless we
must prepare for it right now.

Thanks in advance for your suggestions!

Best,
Mike
__
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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

[Mikhail Fedosin]

Thanks for your help folks!

I proposed a patch for mistral and it seems it works now
https://review.openstack.org/#/c/473796
I'm not a great expert on this issue, so it will be great if someone from
keystone team could review the patch.

Best,
Mike

On Wed, Jun 21, 2017 at 4:15 AM, Jamie Lennox <jamielen...@gmail.com> wrote:

>
>
> On 16 June 2017 at 00:44, Mikhail Fedosin <mfedo...@gmail.com> wrote:
>
>> Thanks György!
>>
>> On Thu, Jun 15, 2017 at 1:55 PM, Gyorgy Szombathelyi <
>> gyorgy.szombathe...@doclerholding.com> wrote:
>>
>>> Hi Mikhail,
>>>
>>> (I'm not from the Keystone team, but did some patches for using
>>> keystonauth1).
>>>
>>> >
>>> > 2. Even if auth_url is set, it can't be used later, because it is not
>>> registered in
>>> > oslo_config [5]
>>>
>>> auth_url is actually a dynamic parameter and depends on the keystone
>>> auth plugin used
>>> (auth_type=xxx). The plugin which needs this parameter, registers it.
>>>
>>
>> Based on this http://paste.openstack.org/show/612664/ I would say that
>> the plugin doesn't register it :(
>> It either can be a bug, or it was done intentionally, I don't know.
>>
>>
>>>
>>> >
>>> > So I would like to get an advise from keystone team and understand
>>> what I
>>> > should do in such cases. Official documentation doesn't add clarity on
>>> the
>>> > matter because it recommends to use auth_uri in some cases and
>>> auth_url in
>>> > others.
>>> > My suggestion is to add auth_url in the list of keystone authtoken
>>> > middleware config options, so that the parameter can be used by the
>>> others.
>>>
>>> Yepp, this makes some confusion, but adding auth_url will make a clash
>>> with
>>> most (all?) authentication plugins. auth_url can be considered as an
>>> 'internal'
>>> option for the keystoneauth1 modules, and not used by anything else (like
>>> the keystonemiddleware itself). However if there would be a more elagant
>>> solution, I would also hear about it.
>>>
>>> >
>>> > Best,
>>> > Mike
>>> >
>>> Br,
>>> György
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> My final thought that we have to use both (auth_url and auth_uri) options
>> in mistral config, which looks ugly, but necessary.
>>
>> Best,
>> Mike
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> Hi,
>
> I feel like the question has been answered in the thread, but as i'm
> largely responsible for this I thought i'd pipe up here.
>
> It's annoying and unfortunate that auth_uri and auth_url look so similar.
> They've actually existed for some time side by side and ended up like that
> out of evolution rather that any thought. Interestingly the first result
> for auth_uri in google is [1]. I'd be happy to rename it for something else
> if we can agree on what.
>
> Regarding your paste (and the reason i popped up), i would consider this a
> bug in mistral. The auth options aren't registered into oslo.config until
> just before the plugin is loaded because depending on what you put in for
> auth_type the options may be different. In practice pretty much every
> plugin has an auth_url, but mistral shouldn't be assuming anything about
> the structure of [keystone_authtoken]. That's the sole responsibility of
> keystonemiddleware and it does change over time.
>
> Jamie
>
>
> [1] https://adam.younglogic.com/2016/06/auth_uri-vs-auth_url/
>
> __
> 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

Re: [openstack-dev] [glance] nominating Abhishek Kekane for glance core

[Mikhail Fedosin]

Wasn't Abhishek a glance core before? What a surprise for me o_O
I thought that he was just being modest and did not put -2 on the patches.

Undoubtedly, we need to correct this misunderstanding as quickly as
possible and invite Abhishek to the core team.

On Mon, Jun 19, 2017 at 5:40 PM, Erno Kuvaja  wrote:

> On Fri, Jun 16, 2017 at 3:26 PM, Brian Rosmaita
>  wrote:
> > I'm nominating Abhishek Kekane (abhishekk on IRC) to be a Glance core
> > for the Pike cycle.  Abhishek has been around the Glance community for
> > a long time and is familiar with the architecture and design patterns
> > used in Glance and its related projects.  He's contributed code,
> > triaged bugs, provided bugfixes, and done quality reviews for Glance.
> >
> > Abhishek has been proposed for Glance core before, but some members of
> > the community were concerned that he wasn't able to devote sufficient
> > time to Glance.  Given the current situation with the project,
> > however, it would be an enormous help to have someone as knowledgeable
> > about Glance as Abhishek to have +2 powers.  I discussed this with
> > Abhishek, he's aware that some in the community have that concern, and
> > he's agreed to be a core reviewer for the Pike cycle.  The community
> > can revisit his status early in Queens.
> >
> > Now that I've written that down, that puts Abhishek in the same boat
> > as all core reviewers, i.e., their levels of participation and
> > commitment are assessed at the beginning of each cycle and adjustments
> > made.
> >
> > In any case, I'd like to put Abhishek to work as soon as possible!  So
> > please reply to this message with comments or concerns before 23:59
> > UTC on Monday 19 June.  I'd like to confirm Abhishek as a core on
> > Tuesday 20 June.
> >
> > thanks,
> > brian
> >
>
> +2 from me! This sounds like a great solution for our immediate
> staffing issues and I'm happy to hear Abhishek would have the cycles
> to help us. Lets hope we get to enjoy his knowledge and good quality
> reviews on many cycles forward.
>
> - Erno
>
> > 
> __
> > 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

Re: [openstack-dev] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

[Mikhail Fedosin]

Thanks György!

On Thu, Jun 15, 2017 at 1:55 PM, Gyorgy Szombathelyi <
gyorgy.szombathe...@doclerholding.com> wrote:

> Hi Mikhail,
>
> (I'm not from the Keystone team, but did some patches for using
> keystonauth1).
>
> >
> > 2. Even if auth_url is set, it can't be used later, because it is not
> registered in
> > oslo_config [5]
>
> auth_url is actually a dynamic parameter and depends on the keystone auth
> plugin used
> (auth_type=xxx). The plugin which needs this parameter, registers it.
>

Based on this http://paste.openstack.org/show/612664/ I would say that the
plugin doesn't register it :(
It either can be a bug, or it was done intentionally, I don't know.


>
> >
> > So I would like to get an advise from keystone team and understand what I
> > should do in such cases. Official documentation doesn't add clarity on
> the
> > matter because it recommends to use auth_uri in some cases and auth_url
> in
> > others.
> > My suggestion is to add auth_url in the list of keystone authtoken
> > middleware config options, so that the parameter can be used by the
> others.
>
> Yepp, this makes some confusion, but adding auth_url will make a clash with
> most (all?) authentication plugins. auth_url can be considered as an
> 'internal'
> option for the keystoneauth1 modules, and not used by anything else (like
> the keystonemiddleware itself). However if there would be a more elagant
> solution, I would also hear about it.
>
> >
> > Best,
> > Mike
> >
> Br,
> György
> __
> 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


My final thought that we have to use both (auth_url and auth_uri) options
in mistral config, which looks ugly, but necessary.

Best,
Mike
__
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] [Keystone][Mistral][Devstack] Confusion between auth_url and auth_uri in keystone middleware

[Mikhail Fedosin]

Recently I decided to remove deprecated parameters from keystone_authtoken
mistral config and replace them with recommended function of devstack [1].
In doing so, I discovered a strange behavior of configuration mechanism,
and specifically parameters auth_uri and auth_url.

1. The parameter auth_url is not included in the list of the middleware
parameters, there is auth_uri only [2]. Nevertheless, it must be present,
because it's required by identity plugin [3]. Attempts to remove or replace
it with the recommended auth_uri result with these stacktraces [4]

2. Even if auth_url is set, it can't be used later, because it is not
registered in oslo_config [5]

So I would like to get an advise from keystone team and understand what I
should do in such cases. Official documentation doesn't add clarity on the
matter because it recommends to use auth_uri in some cases and auth_url in
others.
My suggestion is to add auth_url in the list of keystone authtoken
middleware config options, so that the parameter can be used by the others.

Best,
Mike

[1] https://review.openstack.org/#/c/473796/
[2]
https://github.com/openstack/keystonemiddleware/blob/master/keystonemiddleware/auth_token/_opts.py#L31
[3]
https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/identity.py#L37
[4] http://paste.openstack.org/show/612662/
[5] http://paste.openstack.org/show/612664/
__
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] [all][tc][glance] Glance needs help, it's getting critical

[Mikhail Fedosin]

On Tue, Jun 13, 2017 at 4:43 AM, Flavio Percoco <fla...@redhat.com> wrote:

>
>
> On Mon, Jun 12, 2017, 19:47 Mikhail Fedosin <mfedo...@gmail.com> wrote:
>
>> On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <fla...@redhat.com>
>> wrote:
>>
>>> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
>>>
>>>> My opinion is that Glance stagnates and it's really hard to implement
>>>> new
>>>> features there. In two years, only one major improvement was developed
>>>> (Image Import Refactoring), and no one has tested it in production yet.
>>>> And
>>>> this is in the heyday of the community, as you said!
>>>>
>>>
>>> You're skipping 2 important things here:
>>>
>>> The first one is that focusing on the image import refactor (IIR) was a
>>> community choice. It's fixing a bigger problem that requires more focus.
>>> The
>>> design of the feature took a couple of cycles too, not the
>>> implementation. The
>>> second thing is that the slow pace may also be caused by the lack of
>>> contributors.
>>
>>
>> It's exactly what I'm talking about - implementing medium-size feature
>> (IIR is about 600 lines of code [1][2]) took 1 year of discussions and 1
>> year for implementation of 5 full-time developers. And most importantly, it
>> took all the community attention. What if we need to implement more serious
>> features? How much time will it take, given that there are not so many
>> developers left?
>>
>
>
> What I was referring to is that this is not the normal case. The IIR was a
> special case, which doesn't mean implementing features is easy, as you
> mentioned.
>
> On the other hand OpenStack users have been requesting for new features for
>>>> a long time: I'm talking about mutistore support, versioning of images,
>>>> image slicing (like in docker), validation and conversion of uploading
>>>> data
>>>> and so on. And I can say that it is impossible to implement them without
>>>> breaking Glance. But all this stuff is already done in Glare (multistore
>>>> support is implemented partially, because modifications of glance_store
>>>> are
>>>> required). And if we switch OpenStack to Glare users will get these
>>>> features out of the box.
>>>>
>>>
>>> Some of these features could be implemented in Glance. As you mentioned,
>>> the
>>> code base is over-engineered but it could be simplified.
>>
>>
>> Everything is possible, I know that. But at what cost?
>>
>
>
> Exactly! This is what I'm asking you to help me out with. I'm trying to
> have a constructive discussion on the cost of this and find a sohort term
> solution and then a long term one.
>

> I don't think the current problem is caused by Glance's lack of "exciting"
>>> features and I certainly don't think replacing it with Glare would be of
>>> any
>>> help now. It may be something we want to think about in the future (and
>>> this is
>>> not the first time I say this) but what you're proposing will be an
>>> expensive
>>> distraction from the real problem.
>>
>>
>> And for the very last time - I don't suggest to replace Glance now or
>> even in a year. At the moment, an email with the title "Glance needs help,
>> it's getting critical" is enough.
>> I call to think about the distant future, probably two years or near
>> that. What can prevent Flavio from writing of such emails in T cycle?
>> Bringing people from Nova and Cinder part-time will not work, because, as
>> we discussed above, even medium-size feature requires years of dedicated
>> work, and having their +1 on typo fixes... what's the benefit of that?
>>
>
> Fully agree here. What I think we need is a short term and a long term
> solution. Would you agree with this?
>
> I mentioned in my previous email that I've never been opposed to a future
> transition away from Glance as soon as this happens naturally.
>
> I understand that you're not proposing to replace Glance now. What I was
> trying to understand is why you thought migratinf away from Glance in the
> future would help us now.
>

It won't help immediately for sure. But in long-term I see next benefits:
* We will have two full-time contributors from Nokia (can have more if it's
necessary)
* Architecture is simpler, all functions are small and well documented. I
believe it will take one-two days for a new developer to get accustomed
with it.
* For me i

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

[Mikhail Fedosin]

On Tue, Jun 13, 2017 at 12:01 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 12/06/17 23:20 +0300, Mikhail Fedosin wrote:
>
>> My opinion is that Glance stagnates and it's really hard to implement new
>> features there. In two years, only one major improvement was developed
>> (Image Import Refactoring), and no one has tested it in production yet.
>> And
>> this is in the heyday of the community, as you said!
>>
>
> You're skipping 2 important things here:
>
> The first one is that focusing on the image import refactor (IIR) was a
> community choice. It's fixing a bigger problem that requires more focus.
> The
> design of the feature took a couple of cycles too, not the implementation.
> The
> second thing is that the slow pace may also be caused by the lack of
> contributors.


It's exactly what I'm talking about - implementing medium-size feature (IIR
is about 600 lines of code [1][2]) took 1 year of discussions and 1 year
for implementation of 5 full-time developers. And most importantly, it took
all the community attention. What if we need to implement more serious
features? How much time will it take, given that there are not so many
developers left?


>
>
>
>> On the other hand OpenStack users have been requesting for new features
>> for
>> a long time: I'm talking about mutistore support, versioning of images,
>> image slicing (like in docker), validation and conversion of uploading
>> data
>> and so on. And I can say that it is impossible to implement them without
>> breaking Glance. But all this stuff is already done in Glare (multistore
>> support is implemented partially, because modifications of glance_store
>> are
>> required). And if we switch OpenStack to Glare users will get these
>> features out of the box.
>>
>
> Some of these features could be implemented in Glance. As you mentioned,
> the
> code base is over-engineered but it could be simplified.


Everything is possible, I know that. But at what cost?


>
>
> Then, Glance works with images only, but Glare supports various types of
>> data, like heat and tosca templates. Next week we will add Secrets
>> artifact
>> type to store private data, and Mistral workflows. I mean - we'll have
>> unified catalog of all cloud data with the possibility to combine them in
>> metastructures, when artifact of one type depends on the other.
>>
>
> Glance working only with images is a design choice and I don't think that's
> something bad. I also don't think Glare's support for other artifacts is
> bad.
> Just different choices.


The idea behind Glare is to give operators, but not the developers, the
opportunity to decide what types they want to use. Specify
"enabled_artifact_types=images" in glare.conf and you'll get a service that
works with images only (consider it as a feature if you want ;) ) Glance is
just a special case of Glare, and it's not a big deal for Glare to behave
like Glance in terms of "working only with images".


>
>
>
>> I will repeat it once again, in order to be understood as much as
>> possible.
>> It takes too much time to develop new features and fix old bugs (years to
>> be exact). If we continue in the same spirit, it certainly will not
>> increase the joy of OpenStack users and they will look for other solutions
>> that meet their desires.
>>
>
> Mike, I understand that you think that the broader set of features that
> Glare
> provides would be better for users, which is something I disagree with a
> bit.
> More features don't make a service better. What I'm failing to see,
> though, is
> why you believe that replacing Glance with Glare will solve the current
> problem.


I think that features are important, but sometimes stability matters too!
There are still a lot of dangerous and nasty bugs, that we can't fix
without breaking Glance.


>
> I don't think the current problem is caused by Glance's lack of "exciting"
> features and I certainly don't think replacing it with Glare would be of
> any
> help now. It may be something we want to think about in the future (and
> this is
> not the first time I say this) but what you're proposing will be an
> expensive
> distraction from the real problem.


And for the very last time - I don't suggest to replace Glance now or even
in a year. At the moment, an email with the title "Glance needs help, it's
getting critical" is enough.
I call to think about the distant future, probably two years or near that.
What can prevent Flavio from writing of such emails in T cycle? Bringing
people from Nova and Cinder part-time will not work, because, as we
discussed above, even medium-size feature requires years

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

[Mikhail Fedosin]

Well... My suggestion is to keep Glance maintained and begin experimental
adoption of Glare. So this is not an immediate replacement, but the
evolution of the Image service.
My opinion is that Glance stagnates and it's really hard to implement new
features there. In two years, only one major improvement was developed
(Image Import Refactoring), and no one has tested it in production yet. And
this is in the heyday of the community, as you said!

On the other hand OpenStack users have been requesting for new features for
a long time: I'm talking about mutistore support, versioning of images,
image slicing (like in docker), validation and conversion of uploading data
and so on. And I can say that it is impossible to implement them without
breaking Glance. But all this stuff is already done in Glare (multistore
support is implemented partially, because modifications of glance_store are
required). And if we switch OpenStack to Glare users will get these
features out of the box.

Then, Glance works with images only, but Glare supports various types of
data, like heat and tosca templates. Next week we will add Secrets artifact
type to store private data, and Mistral workflows. I mean - we'll have
unified catalog of all cloud data with the possibility to combine them in
metastructures, when artifact of one type depends on the other.

I will repeat it once again, in order to be understood as much as possible.
It takes too much time to develop new features and fix old bugs (years to
be exact). If we continue in the same spirit, it certainly will not
increase the joy of OpenStack users and they will look for other solutions
that meet their desires.

Best,
Mike

On Mon, Jun 12, 2017 at 10:20 PM, Flavio Percoco <fla...@redhat.com> wrote:

> On 12/06/17 16:56 +0300, Mikhail Fedosin wrote:
>
>> Hello!
>>
>> Flavio raised a very difficult and important question, and I think that
>> we,
>> as community members, should decide what to do with Glance next.
>>
>
> Hi Mike,
>
>
> I will try to state my subjective opinion. I was involved in the Glance
>> project for almost three years and studied it fairly plank. I believe that
>> the main problem is that the project was designed extremely poorly. Glance
>> does not have many tasks to solve, but nevertheless, there are a lot of
>> Java design patterns used (factory of factories, visitors, proxy and other
>> things that are unnecessary in this case). All this leads to absolutely
>> sad
>> consequences, when in order to add an image tag over 180 objects of
>> different classes are created, the code execution passes through more than
>> 25 locations with a number of callbacks 3 times. So I can say that the
>> code
>> base is artificially over-complicated and incredibly inflated.
>>
>> The next problem is that over the years the code has grown by a number of
>> workarounds, which make it difficult to implement new changes - any change
>> leads to something breaking down somewhere else. In the long run, we get a
>> lot of pain associated with race conditions, hard-to-recover heisenbugs
>> and
>> other horrors of programmer's life. It is difficult to talk about
>> attracting new developers, because the developing of the code in such
>> conditions is mentally exhausting.
>>
>
> I don't disagree on this. The code base *is* over-engineered in many areas.
> However, I don't think this is a good reason to just throw the entire
> project
> away. With enough time and contributions, the code could be refactored.
>
> We can continue to deny the obvious, saying that Glance simply needs people
>> and everything will be wonderful. But unfortunately this is not so - we
>> should admit that it is simply not profitable to engage in further
>> development. I suggest thinking about moving the current code base into a
>> support mode and starting to develop an alternative (which I have been
>> doing for the past year and a half).
>>
>> If you are allergic to the word "artifacts", do not read the following
>> paragraph:
>>
>> We are actively developing the Glare project, which offers a universal
>> catalog of various binary data along with its metadata - at the moment the
>> catalog supports the storage of images of virtual machines and has feature
>> parity with Glance. The service is used in production by Nokia, and it was
>> thoroughly tested at various settings. Next week we plan to release the
>> first stable version and begin the integration with various projects of
>> OpenStack: Mistral and Vitrage in the first place.
>>
>> As a solution, I can propose to implement an additional API to Glare,
>> which
>> would correspond to OpenStack Image API v2 and test that

Re: [openstack-dev] [all][tc][glance] Glance needs help, it's getting critical

[Mikhail Fedosin]

Hello!

Flavio raised a very difficult and important question, and I think that we,
as community members, should decide what to do with Glance next.

I will try to state my subjective opinion. I was involved in the Glance
project for almost three years and studied it fairly plank. I believe that
the main problem is that the project was designed extremely poorly. Glance
does not have many tasks to solve, but nevertheless, there are a lot of
Java design patterns used (factory of factories, visitors, proxy and other
things that are unnecessary in this case). All this leads to absolutely sad
consequences, when in order to add an image tag over 180 objects of
different classes are created, the code execution passes through more than
25 locations with a number of callbacks 3 times. So I can say that the code
base is artificially over-complicated and incredibly inflated.

The next problem is that over the years the code has grown by a number of
workarounds, which make it difficult to implement new changes - any change
leads to something breaking down somewhere else. In the long run, we get a
lot of pain associated with race conditions, hard-to-recover heisenbugs and
other horrors of programmer's life. It is difficult to talk about
attracting new developers, because the developing of the code in such
conditions is mentally exhausting.

We can continue to deny the obvious, saying that Glance simply needs people
and everything will be wonderful. But unfortunately this is not so - we
should admit that it is simply not profitable to engage in further
development. I suggest thinking about moving the current code base into a
support mode and starting to develop an alternative (which I have been
doing for the past year and a half).

If you are allergic to the word "artifacts", do not read the following
paragraph:

We are actively developing the Glare project, which offers a universal
catalog of various binary data along with its metadata - at the moment the
catalog supports the storage of images of virtual machines and has feature
parity with Glance. The service is used in production by Nokia, and it was
thoroughly tested at various settings. Next week we plan to release the
first stable version and begin the integration with various projects of
OpenStack: Mistral and Vitrage in the first place.

As a solution, I can propose to implement an additional API to Glare, which
would correspond to OpenStack Image API v2 and test that OpenStack is able
to work on its basis. After that, leave Glance at rest and start developing
Glare as a universal catalog of binary data for OpenStack.

Best,
Mike

On Fri, Jun 9, 2017 at 8:07 PM, Flavio Percoco  wrote:

> (sorry if duplicate, having troubles with email)
>
> Hi Team,
>
> I've been working a bit with the Glance team and trying to help where I
> can and
> I can't but be worried about the critical status of the Glance team.
> Unfortunately, the number of participants in the Glance team has been
> reduced a
> lot resulting in the project not being able to keep up with the goals, the
> reviews required, etc.[0]
>
> I've always said that Glance is one of those critical projects that not
> many
> people notice until it breaks. It's in every OpenStack cloud sitting in a
> corner
> and allowing for VMs to be booted. So, before things get even worse, I'd
> like us to brainstorm a bit on what solutions/options we have now.
>
> I know Glance is not the only project "suffering" from lack of
> contributors but
> I don't want us to get to the point where there won't be contributors left.
>
> How do people feel about adding Glance to the list of "help wanted" areas
> of
> interest?
>
> Would it be possible to get help w/ reviews from folks from teams like
> nova/cinder/keystone? Any help is welcomed, of course, but I'm trying to
> think
> about teams that may be familiar with the Glance code/api already.
>
> Cheers,
> Flavio
>
> [0] http://stackalytics.com/?module=glance-group=marks
> [1] https://review.openstack.org/#/c/466684/
>
> --
> @flaper87
> Flavio Percoco
>
>
> __
> 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

Re: [openstack-dev] [glance] nominating Mike Fedosin for glance core

[Mikhail Fedosin]

Thank you very much for your trust! I will try not to let you down, and be
with the project in these difficult times.

Despite the fact that most of the time I'm involved in the Glare project, I
agree that they have much in common. And at least they both share
glance_store library. For this reason, I'm thinking of implementing the
multi-storage support, where operators can create various settings for
different stores. For instance, having multiple connected ceph data stores.
The rest of the time I plan to review the code, write tests and fix minor
bugs.

I'm glad to be a part of the community!

Best,
Mike

On Fri, May 26, 2017 at 7:28 AM, feilong  wrote:

> Welcome back, Mike.
>
> On 26/05/17 16:21, Kekane, Abhishek wrote:
>
> +1, agree with Nikhil.
>
>
>
> Abhishek
>
>
>
> *From:* Nikhil Komawar [mailto:nik.koma...@gmail.com
> ]
> *Sent:* Friday, May 26, 2017 6:04 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [glance] nominating Mike Fedosin for
> glance core
>
>
>
> This is great news. Always +2 for Mike, he's been great (dev, glancer,
> stacker ..) all the years.  Let's not wait so long for reinstatement if
> folks are on-board, as having another core will only help.
>
>
>
> On Thu, May 25, 2017 at 11:53 AM, Brian Rosmaita <
> rosmaita.foss...@gmail.com> wrote:
>
> As you've no doubt read elsewhere on the ML, we've lost several glance
> cores recently due to employment changes.  Luckily, Mike Fedosin
> informed me at today's Glance weekly meeting that he will have time
> for the next few months to devote some time to Glance reviewing.
>
> For those who don't know Mike (mfedosin on IRC), he was a Glance core
> for several years.  He provided a lot of notes that were used to write
> the Glance architecture documentation that is so helpful to new
> contributors, so he's extremely knowledgeable about the design
> patterns used in Glance.
>
> Most recently, Mike's been working on the Glare project, which has a
> lot in common with Glance.  While Mike says he can't commit much time
> to Glance development, he has proposed porting some of the Glare tests
> over to Glance, which will certainly help with our code coverage, and
> would be a helpful addition to Glance.
>
> (Mike agreed at today's Glance meeting not to propose re-integrating
> Glare into the Glance project until the Queens PTG (if at all), so I'm
> not worried about that being a distraction during the Pike cycle when
> we are so short-handed.)
>
> I'd like to reinstate Mike as a Glance core contributor at the next
> Glance weekly meeting.  Please reply to this message with any comments
> or concerns before 23:59 UTC on Wednesday 31 May 2017.
>
> cheers,
> brian
>
> __
> 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
>
>
>
>
> --
>
> --
>
> Thanks,
>
> Nikhil
>
> __
> Disclaimer: This email and any attachments are sent in strictest confidence
> for the sole use of the addressee and may contain legally privileged,
> confidential, and proprietary data. If you are not the intended recipient,
> please advise the sender by replying promptly to this email and then delete
> and destroy this email and any attachments without any further use, copying
> or forwarding.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --
>
>
> __
> 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] [Glare][Mistral][Murano] Glare client was added to global requirements

[Mikhail Fedosin]

Hello!

I'm happy to announce that recently glare client was added to openstack's
global requirements. Current version (0.3) contains 'glareclient' library,
plugin to openstack client - 'openstack artifact', and a standalone cli -
'glare'.

Now I'm finishing writing the documentation about cli commands and I hope
it will be published this week. It means that soon projects like murano and
mistral may begin the experimental integration with glare v1 api.

If you have any questions - feel free to ask them in our irc channel
#openstack-glare

Best regards,
Mikhail Fedosin
__
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] Arrivederci

[Mikhail Fedosin]

So long, Ian, and good luck on your new job!

You know it has been a pleasure working with you, and I hope we'll meet
again many times. So do not get lost and take care of yourself!

Best,
Mike

P.S. ketogenic diet doesn't work

On Wed, Mar 22, 2017 at 4:07 PM, Luke Hinds  wrote:

>
>
> On Wed, Mar 22, 2017 at 12:06 PM, Ian Cordasco 
> wrote:
>
>> Hi everyone,
>>
>> Friday 24 March 2017 will be my last day working on OpenStack. I'll remove
>> myself from teams (glance, craton, security, hacking) on Friday and
>> unsubscribe
>> from the OpenStack mailing lists.
>>
>> I want to thank all of you for the last ~3 years. I've learned quite a bit
>> from all of you. It's been a unique privilege to call the people in this
>> community my colleagues. Treat each other well. Don't let minor technical
>> arguments cause rifts in the community. Lift each other up.
>>
>> As for me, I'm moving onto something completely different. You all are
>> welcome
>> to keep in touch via email, IRC, or some other method. At the very
>> least, I'll see y'all
>> around PyCon, the larger F/OSS world, etc.
>>
>> --
>> Ian Cordasco
>> IRC/Git{Hub,Lab}/Twitter: sigmavirus24
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Hi Ian,
>
> A loss for OpenStack, but also a big gain for the next community you
> participate in! Wish you best of luck, thanks for all the effort put in.
> Its been great working and learning alongside you in the security project.
>
> Cheers,
>
> Luke
>
> __
> 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

Re: [openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG

[Mikhail Fedosin]

Okay, it seems I did not express myself very well :) But then there is a
rhetorical question: if it's officially recommended to use the service with
the name that starts with "S", why does Nova use a service with the name
beginning with "G" to store its images?

As you may know Glare is a proxy to Swift, Ceph and other possible cloud
storages, and it provides an abstraction (artifact) upon them + several
additional features (like custom data validation and conversion) that Swift
doesn't and shouldn't have. And for sure I was talking about secure and
customizable catalog of binary data with its metadata, and not the concrete
storage implementation. Sorry again for this confusion :)

Best,
Mike

On Mon, Feb 13, 2017 at 8:04 PM, Ian Cordasco <sigmaviru...@gmail.com>
wrote:

> -Original Message-
> From: Jeremy Stanley <fu...@yuggoth.org>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Date: February 13, 2017 at 10:14:24
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [tc][glance][glare][all]
> glance/glare/artifacts/images at the PTG
>
> > On 2017-02-13 18:23:19 +0300 (+0300), Mikhail Fedosin wrote:
> > [...]
> > > Almost every project works with some binary data and must store it
> > > somewhere, and almost always storage itself is not the part of the
> > > project's mission. This issue has often been neglected. For this reason
> > > there is no single recommended method for storing of binary data, which
> > > would have a unified public api and hide all the things of the internal
> > > storage infrastructure.
> > [...]
> >
> > If you'll forgive the sarcasm, it sounds like you're proposing that
> > OpenStack components should be able to rely on the existence of a
> > standard service suitable for generalized storage and retrieval of
> > arbitrary blobs of data through an API. Our trademark
> > interoperability requirements may even guarantee the presence of one
> > already in any compliant deployment; I'll have to check... ;)
>
> Well it's a storage service, so I hope the name doesn't start with "S". ;D
>
> --
> Ian Cordasco
>
> __
> 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

Re: [openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG

[Mikhail Fedosin]

Hello!


Let me quickly describe my vision of the problem. I asked this question to
Brian last Friday, because it is evident that the projects have the
intersection in functionality. For this reason, I proposed to bring Glare
back and develop it as a new generation of Glance service. Perhaps such a
solution would be more correct from my point of view.

Moving away from Glance, let me remind you why we created Glare service.

Almost every project works with some binary data and must store it
somewhere, and almost always storage itself is not the part of the
project's mission. This issue has often been neglected. For this reason
there is no single recommended method for storing of binary data, which
would have a unified public api and hide all the things of the internal
storage infrastructure.

These questions were answered by Glare. First of all, the service allows to
use different storages for various types of artifacts - an operator can
assign the storage of large files, such as virtual machine images, to
Swift, and for relatively small ones, such as Heat templates, use a mysql
database.

Then, we have to admit that data tends to change, so we added a versioning
of artifacts and dependencies between them, that the user was convenient to
take the data of required version.

Often a "binary data" refers to more than one specific object, but a whole
lot of files. Therefore, we have implemented the ability to create
arbitrary nested folders per one artifact and store multiple files there.
And for sure users can receive any file with a single API request.

For validation and conversion of uploaded data Glare introduces the concept
of hooks for the operation. Thus the operator can extend the basic
functionality of the system and add integration with third-party systems
for each artifact type. For example, for Nokia we implemented integration
with custom TOSCA validator.

This is just a small overview of the key features of the service. For sure,
at the moment Glare is able to do all that Glance can do (except maybe a
sharing of artifacts), on the other hand we have added a number of new
features, that were requested by cloud operators for a long time.

Fyi, now we in Nokia are preparing additional API, which corresponds to the
ETSI VNF Packaging Specification [1]. So support of Image v2 API is not an
impossible task, and we may implement it as an alternative way of
interaction with "Images" artifact type. In this case Nova and other
services using Glance are absolutely indifferent to what service provides
Image API.

All tasks related to documentation and packaging are solvable. We’re
working on them together with Nokia, so I can assure you that the documents
and packages will be available this spring. The same story is for Ansible
and Puppet.

Now back again to our question. What I'd like is that Glare will receive
due recognition. Doing a project on the outskirts of OpenStack is not I
really want to. Therefore, it would be nice to develop Glare as a natural
evolution of Glance, associated with the requirements of operators and the
market in general. For Glance team is a good chance to try something new
and interesting, and of course gain new experience.

I am ready to discuss all these questions in this thread, and at PTG, as
long as necessary.

Best,

Mike

[1]
http://www.etsi.org/deliver/etsi_gs/NFV-IFA/001_099/011/02.01.01_60/gs_NFV-IFA011v020101p.pdf

On Fri, Feb 10, 2017 at 8:39 PM, Brian Rosmaita 
wrote:

> I want to give all interested parties a heads up that I have scheduled a
> session in the Macon room from 9:30-10:30 a.m. on Thursday morning
> (February 23).
>
> Here's what we need to discuss.  This is from my perspective as Glance
> PTL, so it's going to be Glance-centric.  This is a quick narrative
> description; please go to the session etherpad [0] to turn this into a
> specific set of discussion items.
>
> Glance is the OpenStack image cataloging and delivery service.  A few
> cycles ago (Juno?), someone noticed that maybe Glance could be
> generalized so that instead of storing image metadata and image data,
> Glance could store arbitrary digital "stuff" along with metadata
> describing the "stuff".  Some people (like me) thought that this was an
> obvious direction for Glance to take, but others (maybe wiser, cooler
> heads) thought that Glance needed to focus on image cataloging and
> delivery and make sure it did a good job at that.  Anyway, the Glance
> mission statement was changed to include artifacts, but the Glance
> community never embraced them 100%, and in Newton, Glare split off as
> its own project (which made sense to me, there was too much unclarity in
> Glance about how Glare fit in, and we were holding back development, and
> besides we needed to focus on images), and the Glance mission statement
> was re-amended specifically to exclude artifacts and focus on images and
> metadata definitions.
>
> OK, so the current situation is:
> - Glance "does" 

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Serg, you forgot that Glare v1 != Glare v0.1. And there is a small issue -
Glare v0.1 is deprecated. So I'm just wondering what are your future plans
about Glare v1. Will you use it or simply copy the v0.1 code into Murano
repo?

Best,
Mike

On Thu, Jan 26, 2017 at 2:03 AM, Serg Melikyan <smelik...@mirantis.com>
wrote:

> I would like to comment a little bit regarding usage of Glare in
> Murano and Mirantis OpenStack:
>
> > How much have these projects adopted Glare?
> Glare is preferred backend for storing murano packages, which provides
> versioning capabilities (they are not available without it)
>
> >Is Glare being deployed already?
> Mirantis OpenStack 9.0 by default is deploying Murano with Glare used
> as a backend.
>
> >What projects are the main consumers of Glare?
> Murano
>
> On Wed, Jan 25, 2017 at 2:56 PM, Mike Perez <thin...@gmail.com> wrote:
> > On 18:16 Jan 24, Mikhail Fedosin wrote:
> >> Hey, Flavio :) Thanks for your questions!
> >>
> >> As you said currently only Nokia's adopting Glare for its own platform,
> but
> >> if we talk about OpenStack, that I believe Mistral will start to use it
> >> soon.
> >> In my opinion Glare's adoption is low due to the fact that the project
> is
> >> not included under Big Tent. I think it will be changed soon, because
> now
> >> I'm finishing Glare v1 API proposal, and when it's done we will apply
> under
> >> BT.
> >>
> >> About Glance v2 API - as I said they are +- the same with several
> cosmetic
> >> differences (in Glance status is called 'queued', in Glare we renamed
> it to
> >> 'drafted', and so on). For this reason I'm going to implement a
> middleware,
> >> that will provide a full Image API v2 for Glare (even with unnecessary
> >> '/v2' prefix) and glance clients will be able to communicate with it as
> >> with Glance. It's definitely doable and we can discuss it more detailed
> >> during the PTG.
> >
> > Both Flavio and Doug asked you to expand on the issues with the Glance
> API. Can
> > you please expand on that.
> >
> > --
> > Mike Perez
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Serg Melikyan, Development Manager at Mirantis, Inc.
> http://mirantis.com | smelik...@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

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Thanks Renat! I agree, currently we do not have a specific plan, and also
several required features, like storing small blobs in database, are not
merged yet. We definitely should talk about it more detailed during (and
probably before) PTG. At least one session will be dedicated directly to
this and all people are welcome to participate!

Best,
Mike



On Fri, Jan 27, 2017 at 7:26 AM, Renat Akhmerov <renat.akhme...@gmail.com>
wrote:

>
> On 26 Jan 2017, at 22:29, Dougal Matthews <dou...@redhat.com> wrote:
>
>
>
> On 24 January 2017 at 16:16, Mikhail Fedosin <mfedo...@gmail.com> wrote:
>
>> Hey, Flavio :) Thanks for your questions!
>>
>> As you said currently only Nokia's adopting Glare for its own platform,
>> but if we talk about OpenStack, that I believe Mistral will start to use it
>> soon.
>>
>
> Has there been some discussion surrounding Mistral and Glare? I'd be
> interested in reading more about those plans and ideas.
>
>
> Dougal, I’ve cherished this idea for a long time and discussed it with a
> few people, but informally.
> I believe we didn’t have any official discussions around it yet. I
> included the corresponding topic
> to our PTG etherpad to finally get this going. Mike and will bring this
> topic up to discussion.
> I believe it’s worth it. We can also discuss basics before the PTG too,
> but in a separate thread.
>
> Renat Akhmerov
> @Nokia
>
>
> __
> 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

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Hey, Flavio :) Thanks for your questions!

As you said currently only Nokia's adopting Glare for its own platform, but
if we talk about OpenStack, that I believe Mistral will start to use it
soon.
In my opinion Glare's adoption is low due to the fact that the project is
not included under Big Tent. I think it will be changed soon, because now
I'm finishing Glare v1 API proposal, and when it's done we will apply under
BT.

About Glance v2 API - as I said they are +- the same with several cosmetic
differences (in Glance status is called 'queued', in Glare we renamed it to
'drafted', and so on). For this reason I'm going to implement a middleware,
that will provide a full Image API v2 for Glare (even with unnecessary
'/v2' prefix) and glance clients will be able to communicate with it as
with Glance. It's definitely doable and we can discuss it more detailed
during the PTG.

Best,
Mike

On Mon, Jan 23, 2017 at 11:51 AM, Flavio Percoco <fla...@redhat.com> wrote:

> On 19/01/17 12:48 +0300, Mikhail Fedosin wrote:
>
>> Hi Matt!
>>
>> This should be discussed, for sure, but there is a lot of potential. In
>> general, it depends on how far we are willing to go. In the minimum
>> approximation we can seamlessly replace Glance with Glare and operators
>> simply get additional features for versioning, validation (and conversion,
>> if necessary) of their uploaded images on the fly, as well as support for
>> storing files in different stores.
>>
>> If we dig a little deeper, then Glare allows you to store multiple files
>> in
>> a single artifact, so we can create a new type (ec2_image) and define
>> three
>> blobs inside: ami, ari, aki, and upload all three as a single object. This
>> will get rid of a large amount of legacy code and simplify the
>> architecture
>> of Nova. Plus Glare will control the integrity of such artifact.
>>
>
> Hey Mike,
>
> Thanks for bringing this up. While I think there's potential in Glare
> given it's
> being created during a more mature age of OpenStack and based on matured
> principles and standards, I believe you may be promoting Glare using the
> wrong
> arguments.
>
> As you mentioned in your first email on this thread, Glare has a set of
> functionalities that are already useful to a set of existing projects.
> This is
> great and I'd probably start from there.
>
> * How much have these projects adopted Glare?
> * Is Glare being deployed already?
> * What projects are the main consumers of Glare?
>
> Unfortunately, replacing Glance is not as simple as dropping Glare in
> because
> it's not only being used by Nova. Glance is also a public API (at least
> v2) and
> there are integrations that have been built by either cloud providers or
> cloud
> consumers on top of the existing Glance API.
>
> If Glare ships a Glance compatible API (as a way to make a drop-in
> replacement
> possible), it'll have to support it and live with it for a long time. In
> addition to this, Glare will have to keep up with the changes that may
> happen in
> Glance's API during that time.
>
> The next step could be full support for OVF and other formats that require
>> a large number of files. Here we can use artifact folders and put all the
>> files there.
>> "OpenStack Compute does not currently have support for OVF packages, so
>> you
>> will need to extract the image file(s) from an OVF package if you wish to
>> use it with OpenStack."
>> http://docs.openstack.org/image-guide/introduction.html
>>
>> Finally, I notice that there are a few nasty bugs in Glance (you know what
>> I mean), which make it extremely inconvenient for a number of deployments.
>>
>
> Not everyone is familiar with the issues of Glance's API. I believe I know
> what
> you're referring to but I'd recommend to expand here for the sake of
> discussion.
>
> That being said, I'd also like to point out that the flaws of Glance's API
> could
> be fixed so I'd rather focus the discussion on the benefits Glare would
> bring
> rather than how Glance's API may or may not be terrible. That's the kind of
> competition I'd prefer to see in this discussion.
>
> Cheers,
> Flavio
>
>
> On Wed, Jan 18, 2017 at 8:26 PM, Matt Riedemann <
>> mrie...@linux.vnet.ibm.com>
>> wrote:
>>
>> On 1/18/2017 10:54 AM, Mikhail Fedosin wrote:
>>>
>>> Hello!
>>>>
>>>> In this letter I want to tell you the current status of Glare project
>>>> and discuss its future development within the entire OpenStack
>>>> community.
>>>>
>>>> In the beginning I have to say a few words about myself - my nam

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Glare does not compete with Swift, it uses this service as one of the
possible backeds. On the whole I should note that in some cases the use of
Swift is excessive: for example, for small files (a few kilobytes), it is
easier to store them directly in the database. And Glare just let you do
this - to keep large files in stores like Swift or Ceph, and use a more
appropriate location for small ones.

Plus, Swift does not provide data immutability. Where is the guarantee that
user won't change his files in Swift or completely remove them? Glare
manages this behavior and provides full immutability for stored data,
regardless of the backend. In general, to address these immutability issues
Glance was invented in due time. But now we see that its functionality is
not enough and it's really hard to extend it.

On Thu, Jan 19, 2017 at 6:25 AM, Lingxian Kong <anlin.k...@gmail.com> wrote:

>
> On Thu, Jan 19, 2017 at 5:54 AM, Mikhail Fedosin <mfedo...@gmail.com>
> wrote:
>
>> And here I want to ask the community - how exactly Glare may be useful in
>> OpenStack? Glare was developed as a repository for all possible data types,
>> and it has many possible applications. For example, it's a storage of vm
>> images for Nova. Currently Glance is used for this, but Glare has much more
>> features and this transition is easy to implement. Then it's a storage of
>> Tosca templates. We were discussing integration with Heat and storing
>> templates and environments in Glare, also it may be interesting for TripleO
>> project. Mistral will store its workflows in Glare, it has already been
>> decided. I'm not sure if Murano project is still alive, but they already
>> use Glare 0.1 from Glance repo and it will be removed soon (in Pike afaik),
>> so they have no other options except to start using Glare v1. Finally there
>> were rumors about storing torrent files from Ironic.
>
>
> ​Seems Swift already could do such things.​
>
>
> Cheers,
> Lingxian Kong (Larry)
>
> __
> 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

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

On Wed, Jan 18, 2017 at 9:30 PM, Doug Hellmann 
wrote:

> Excerpts from Mikhail Fedosin's message of 2017-01-18 19:54:01 +0300:
> > Hello!
> >
> > In this letter I want to tell you the current status of Glare project and
> > discuss its future development within the entire OpenStack community.
> >
> > In the beginning I have to say a few words about myself - my name is Mike
> > and I am the PTL of Glare. Currently I work as a consultant at Nokia,
> where
> > we're developing the service as a universal catalog of binary data. As I
> > understand it right, Nokia has big plans for this service, Moshe Elisha
> can
> > tell you more about them.
> >
> > And here I want to ask the community - how exactly Glare may be useful in
> > OpenStack? Glare was developed as a repository for all possible data
> types,
> > and it has many possible applications. For example, it's a storage of vm
> > images for Nova. Currently Glance is used for this, but Glare has much
> more
> > features and this transition is easy to implement. Then it's a storage of
>
> Is there actually an upgrade path today, or is that something someone
> would have to build?
>

We're discussing it with Glance community. Today there will be an IRC
meeting and I'll present my plans there.


>
> > Tosca templates. We were discussing integration with Heat and storing
> > templates and environments in Glare, also it may be interesting for
> TripleO
> > project. Mistral will store its workflows in Glare, it has already been
> > decided. I'm not sure if Murano project is still alive, but they already
> > use Glare 0.1 from Glance repo and it will be removed soon (in Pike
> afaik),
> > so they have no other options except to start using Glare v1. Finally
> there
> > were rumors about storing torrent files from Ironic.
>
> Glare is not currently an official project, and it seems to have
> very few contributors during the Ocata time frame. Do either of
> those things concern any of the project teams considering adding
> it as a dependency? Do you have plans to address those?
>

Absolutely correct observation! Unfortunately there was a hitch in the
service development caused by problems in the organization of my previous
employer. Now I try again to put the project on the right track. At least
Nokia will use Glare in production and allocates two people on it. In
addition, I received a notice from a few people who are interested in
contribution in Glare, I'll call some of them:

Geetika Batra from Red Hat
Dharini Chandrasekar from Intel
Darja Malyavkina, independent
Danil Golov from Samsung
Kairat Kushaev from Mirantis
Hemanth Makkapati from Rackspace

I think we should ask them to confirm their agreements in this thread.

Finally I'm going to announce that we'll apply under Big Tent till the end
of January.


>
> Doug
>
> >
> > Now let me briefly describe Glare features:
> >
> >  * Versioning of artifacts - each artifact has a version in SemVer format
> > and you can sort and filter by this field.
> >  * Multiblob support - there can be several files and folders per one
> > artifact.
> >  * The ease of creating new artifact types with oslo_versionedobjects
> > framework.
> >  * Fair immutability - no one can change artifact when it's active.
> >  * Multistore support - each artifact type data may be stored in
> different
> > storages: images may go to Swift; heat templates may be stored directly
> in
> > sql-database; for Docker Contatiners you can use Ceph, if you want.
> >  * Advanced sorting and filtering with various operators.
> >  * Uploaded data validation and conversion with hooks - for example,
> Glare
> > may check if uploaded file was a valid Tosca template and return Bad
> > Request if it's not.
> >
> > If you're interested, I recorded several demos in asciinema, that
> describe
> > how Glare works and present the most useful features. Another demo about
> > uploading hooks will be recorded and published this week.
> >
> > So, please tell me what you think and recommend in what direction we
> should
> > develop the project. Thanks in advance!
> >
> > Best,
> > Mike
> >
> > Useful links:
> > [1] Api documentation in rst format:
> > https://etherpad.openstack.org/p/glare-api
> > [2] Basic artifact workflow on devstack: https://asciinema.org/a/97985
> > [3] Listing of artifacts: https://asciinema.org/a/97986
> > [4] Creating your own artifact type with oslo_vo:
> > https://asciinema.org/a/97987
> > [5] Locations, Tags, Links and Folders in Glare:
> > https://asciinema.org/a/99771
>
> __
> 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: 

Re: [openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Hi Matt!

This should be discussed, for sure, but there is a lot of potential. In
general, it depends on how far we are willing to go. In the minimum
approximation we can seamlessly replace Glance with Glare and operators
simply get additional features for versioning, validation (and conversion,
if necessary) of their uploaded images on the fly, as well as support for
storing files in different stores.

If we dig a little deeper, then Glare allows you to store multiple files in
a single artifact, so we can create a new type (ec2_image) and define three
blobs inside: ami, ari, aki, and upload all three as a single object. This
will get rid of a large amount of legacy code and simplify the architecture
of Nova. Plus Glare will control the integrity of such artifact.

The next step could be full support for OVF and other formats that require
a large number of files. Here we can use artifact folders and put all the
files there.
"OpenStack Compute does not currently have support for OVF packages, so you
will need to extract the image file(s) from an OVF package if you wish to
use it with OpenStack."
http://docs.openstack.org/image-guide/introduction.html

Finally, I notice that there are a few nasty bugs in Glance (you know what
I mean), which make it extremely inconvenient for a number of deployments.

On Wed, Jan 18, 2017 at 8:26 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

> On 1/18/2017 10:54 AM, Mikhail Fedosin wrote:
>
>> Hello!
>>
>> In this letter I want to tell you the current status of Glare project
>> and discuss its future development within the entire OpenStack community.
>>
>> In the beginning I have to say a few words about myself - my name is
>> Mike and I am the PTL of Glare. Currently I work as a consultant at
>> Nokia, where we're developing the service as a universal catalog of
>> binary data. As I understand it right, Nokia has big plans for this
>> service, Moshe Elisha can tell you more about them.
>>
>> And here I want to ask the community - how exactly Glare may be useful
>> in OpenStack? Glare was developed as a repository for all possible data
>> types, and it has many possible applications. For example, it's a
>> storage of vm images for Nova. Currently Glance is used for this, but
>> Glare has much more features and this transition is easy to implement.
>> Then it's a storage of Tosca templates. We were discussing integration
>> with Heat and storing templates and environments in Glare, also it may
>> be interesting for TripleO project. Mistral will store its workflows in
>> Glare, it has already been decided. I'm not sure if Murano project is
>> still alive, but they already use Glare 0.1 from Glance repo and it will
>> be removed soon (in Pike afaik), so they have no other options except to
>> start using Glare v1. Finally there were rumors about storing torrent
>> files from Ironic.
>>
>> Now let me briefly describe Glare features:
>>
>>  * Versioning of artifacts - each artifact has a version in SemVer
>> format and you can sort and filter by this field.
>>  * Multiblob support - there can be several files and folders per one
>> artifact.
>>  * The ease of creating new artifact types with oslo_versionedobjects
>> framework.
>>  * Fair immutability - no one can change artifact when it's active.
>>  * Multistore support - each artifact type data may be stored in
>> different storages: images may go to Swift; heat templates may be stored
>> directly in sql-database; for Docker Contatiners you can use Ceph, if
>> you want.
>>  * Advanced sorting and filtering with various operators.
>>  * Uploaded data validation and conversion with hooks - for example,
>> Glare may check if uploaded file was a valid Tosca template and return
>> Bad Request if it's not.
>>
>> If you're interested, I recorded several demos in asciinema, that
>> describe how Glare works and present the most useful features. Another
>> demo about uploading hooks will be recorded and published this week.
>>
>> So, please tell me what you think and recommend in what direction we
>> should develop the project. Thanks in advance!
>>
>> Best,
>> Mike
>>
>> Useful links:
>> [1] Api documentation in rst format:
>> https://etherpad.openstack.org/p/glare-api
>> [2] Basic artifact workflow on devstack: https://asciinema.org/a/97985
>> [3] Listing of artifacts: https://asciinema.org/a/97986
>> [4] Creating your own artifact type with oslo_vo:
>> https://asciinema.org/a/97987
>> [5] Locations, Tags, Links and Folders in Glare:
>> https://asciinema.org/a/99771
>>
>>
>> __

[openstack-dev] [TC][Glance][Nova][TripleO][Heat][Mistral][Ironic][Murano] Glare

[Mikhail Fedosin]

Hello!

In this letter I want to tell you the current status of Glare project and
discuss its future development within the entire OpenStack community.

In the beginning I have to say a few words about myself - my name is Mike
and I am the PTL of Glare. Currently I work as a consultant at Nokia, where
we're developing the service as a universal catalog of binary data. As I
understand it right, Nokia has big plans for this service, Moshe Elisha can
tell you more about them.

And here I want to ask the community - how exactly Glare may be useful in
OpenStack? Glare was developed as a repository for all possible data types,
and it has many possible applications. For example, it's a storage of vm
images for Nova. Currently Glance is used for this, but Glare has much more
features and this transition is easy to implement. Then it's a storage of
Tosca templates. We were discussing integration with Heat and storing
templates and environments in Glare, also it may be interesting for TripleO
project. Mistral will store its workflows in Glare, it has already been
decided. I'm not sure if Murano project is still alive, but they already
use Glare 0.1 from Glance repo and it will be removed soon (in Pike afaik),
so they have no other options except to start using Glare v1. Finally there
were rumors about storing torrent files from Ironic.

Now let me briefly describe Glare features:

 * Versioning of artifacts - each artifact has a version in SemVer format
and you can sort and filter by this field.
 * Multiblob support - there can be several files and folders per one
artifact.
 * The ease of creating new artifact types with oslo_versionedobjects
framework.
 * Fair immutability - no one can change artifact when it's active.
 * Multistore support - each artifact type data may be stored in different
storages: images may go to Swift; heat templates may be stored directly in
sql-database; for Docker Contatiners you can use Ceph, if you want.
 * Advanced sorting and filtering with various operators.
 * Uploaded data validation and conversion with hooks - for example, Glare
may check if uploaded file was a valid Tosca template and return Bad
Request if it's not.

If you're interested, I recorded several demos in asciinema, that describe
how Glare works and present the most useful features. Another demo about
uploading hooks will be recorded and published this week.

So, please tell me what you think and recommend in what direction we should
develop the project. Thanks in advance!

Best,
Mike

Useful links:
[1] Api documentation in rst format:
https://etherpad.openstack.org/p/glare-api
[2] Basic artifact workflow on devstack: https://asciinema.org/a/97985
[3] Listing of artifacts: https://asciinema.org/a/97986
[4] Creating your own artifact type with oslo_vo:
https://asciinema.org/a/97987
[5] Locations, Tags, Links and Folders in Glare:
https://asciinema.org/a/99771
__
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] [Zun][Glare][Glance] Building Docker images

[Mikhail Fedosin]

I believe we can add Glare driver to Zun [1] and allow it to pull container
images from Glare directly. Then, as Kairat mentioned, we should prepare
'container-images' artifact type for Glare [2]. For sure, we can use
'images' (which are actually vm images) to store containers, but it's ugly,
because virtual machine is not exactly the same as container. If it's
required let me know, and I'll propose related patches to Zun and Glare.

Best,
Mike

[1] https://github.com/openstack/zun/tree/master/zun/image
[2] https://github.com/openstack/glare/tree/master/glare/objects

On Fri, Dec 16, 2016 at 3:36 PM, Kairat Kushaev 
wrote:

> Hello Denis,
> unfortunately, I don't have deep knowledge of Zun so i can speak from
> Glare side only.
> So Glare can serve as some kind of artifact storage for container files
> but we need to define artifact structure first.
> Please note that artifact is immutable after activation so once you need
> to change some files you need to create new artifact.
> Also there is possibility to store container images in Glare also but this
> requires an integration from Zun to consume blobs from Glare.
> So it requires some improvements outside Glare.
>
> Best regards,
> Kairat Kushaev
>
> On Tue, Dec 13, 2016 at 8:16 PM, Hongbin Lu  wrote:
>
>> Denis,
>>
>>
>>
>> Per my understanding, container image building is out of the scope of the
>> Zun project. Zun assumes an image has been built and uploaded to a image
>> repository (i.e. Glance, docker registry), then the image will be pulled
>> down from the repo to host. However, feel free to let us know if anything
>> else we can do.
>>
>>
>>
>> Best regards,
>>
>> Hongbin
>>
>>
>>
>> *From:* Denis Makogon [mailto:lildee1...@gmail.com]
>> *Sent:* December-12-16 4:51 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> *Subject:* [openstack-dev] [Zun][Glare][Glance] Building Docker images
>>
>>
>>
>> Hello to All.
>>
>>
>>
>> I’d like to get initial feedback on the idea of building Docker images
>> through Zun involving Glare as artifactory for all static components
>> required for image.
>>
>>   So, the idea here is in being capable to build a Docker image
>> through Zun API with storing all static data required for docker image
>> building in Glare or Swift. In order to keep the same UX from using Docker
>> it would be better to use Dockerfile as description format for image
>> building.
>>
>>   In image creation process Glare could take role of
>> artifactory, where users stores, let’s say source code of his applications
>> that would run in containers, static data, etc. And those artifacts will be
>> pulled during image creation and used to inject into image (similar process
>> of context creation during Docker image building using native CLI). Please
>> note that artifacts are completely optional for images, but would give a
>> capability to keep artifacts in dedicated storage instead of transferring
>> all data through Zun API (the opposite concept to Docker build context).
>>
>>
>>
>>   Once image is created, it can be stored in underlying Docker
>> in Zun or can be published into Glance or Swift for further consumption (if
>> user will need to save image, he’ll use Glance image download API). I’ve
>> mentioned Swift VS Glance because Swift has concept of temp URLs that can
>> be accessed without being authorized. Such feature allows to use Swift as
>> storage from where possible to export image to Docker using Import API [1].
>>
>>
>>
>>
>>
>> Any feedback on the idea is appreciated.
>>
>>
>>
>> Kind regards,
>>
>> Denis Makogon
>>
>>
>>
>> [1] https://docs.docker.com/engine/reference/commandline/import/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-dev] [Kuryr][Magnum] How stable is kuryr-kubernetes?

[Mikhail Fedosin]

Hi folks!

We at Samsung are trying to integrate containers in OpenStack and at this
moment we are looking at Kubernetes deployed by Magnum, which works good
enough for now.

One challenge we have faced recently is making containers able to
communicate with Nova VM instances (in other words we want to integrate
Neutron in Kubernetes) and Kuryr seems to be a right solution (based on its
description). Unfortunately there is a lack of documentation, but from
various presentations on youtube I got that kuryr has been split in two
projects (kuryr-libnetwork for Docker Swarm and kuryr-kubernetes for
Kubernetes respectively, and they both share a common library called
"kuryr"). kuryr-libnetwork continues previous works, which the community
has been implementing for over a year. It looks stable, nevertheless it
doesn't work with the latest Docker 1.12. kuryr-kubernetes is rather new,
and I wonder if it can be already used (at least on devstack), or maybe
some further efforts are required.

Then please enlighten me about current status of Magnum-Kuryr integration.
I saw that this was discussed in Barcelona and Austin, but in Magnum's
master it's still unavailable. Also it will be great if you point at the
responsible person with whom I can discuss it more detailed and see how I
can be involved in the development.

Thanks,
Mike
__
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] [glare] Few questions regarding OpenStack Glare

[Mikhail Fedosin]

Hi Moshe! Thank you for your interest in the project. I answered your
questions below.

On Mon, Nov 7, 2016 at 3:13 PM, Elisha, Moshe (Nokia - IL) <
moshe.eli...@nokia.com> wrote:

> Hi,
>
>
>
> My name is Moshe Elisha and I work at CloudBand, Nokia.
>
> I watched "Glare - A Unified Binary Repository for OpenStack[1]" and it
> looks very nice and useful.
>
>
>
> We are considering using Glare as a standalone artifacts repository.
>
> We have two main use cases:
>
> A. Create a custom artifact_type which basically has one archive file
> (BLOB).
>
> B. Use "images" artifact type to store images.
>
>
>
> I have a few questions that I couldn't find the answer for and I would
> appreciate it if you could please reply:
>
>
>
> 1.  What dependencies does Glare have on other OpenStack services? Is
> it only a dependency in Keystone?
>
Glare may be a standalone service: for example for App-Catalog we use it
with custom auth middleware without Keystone. Another optional dependency
is Swift.

> 2.  I saw that there is a way to implement a "validate_upload" hook.
> Is there a support for an async validation process (in case validation
> process is long)?
>
For big files uploads we're going to implement integration with OpenStack
Mistral to have them as asynchronous tasks. Currently all uploads are
synchronous.

> 3.  Is there a way to define the "backend" used per artifact_type?
> For example, "heat_templates" will be stored on "File system" and "images"
> will be stored on "Ceph"?
>
For your particular case - yes. You may specify function
"get_default_store" for you artifact type and return desired backend. It's
highly flexible and allows to define your backend dynamically, based on
user's context, current artifact values or blob name. Unfortunately
glance_store doesn't support several backends of one type, like 3 different
cephs. I believe it will be achieved during Ocata cycle and we'll be able
to talk about true multibackendness :)

> 4.  Were there talks about a "Database" backend? Probably only
> relevant for some artifact types.
>
For doing this we will have to add new driver to glance_store and I'm 100%
sure that glance community will be against this initiative. But it's
doable: in the worst case we can get rid of glance_store library and add
all the necessary functionality right in Glare repo.

> 5.  Disregarding the "backend" used – is there anything that prevents
> Glare from running in HA active/active mode?
>
I do not see any obstacles.

> 6.  With regards to "backend" – which of the currently supported
> backends is preferable in order to achieve HA active/active mode?
>
If I understand you correctly - all, except 'file'.

> 7.  I noticed that there is a puppet-glare[2] project. Can you please
> share the status of that project?
>
Frankly speaking I don't know. Some Mirantis folks worked on it a month
ago, but now they don't. All I know - this puppet is good enough for
deploying new App-Catalog with Glare backend.

> 8.  Is there any work being done for creating RPMs for glare?
>
Afaik no. We need a volunteer from RDO community for this.

>
>
> [1] https://www.youtube.com/watch?v=uBtqdXciF4A
>
> [2] https://github.com/openstack/puppet-glare
>
> [3] https://github.com/openstack-packages
>
>
>
>
>
> Thanks!
>
>
>
>
>
> Moshe Elisha,
>
> R Director,
>
> CloudBand Network Director, Nokia.
>
> __
> 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

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Mikhail Fedosin]

Agree :) +1 for both of them!

Best,
Mike

On Mon, Oct 24, 2016 at 6:31 PM, Michael Xin  wrote:

> +1 for both.
>
> yours,
> Michael
>
> On Fri, Oct 21, 2016 at 3:07 AM, Flavio Percoco  wrote:
>
>> On 20/10/16 12:33 -0700, Steve Lewis wrote:
>>
>>> I'm not voicing as a core here, but in the course of several cycles I
>>> have
>>> seen Erno and Ian each providing the care and insight needed by this role
>>> and trust them to do the job well.
>>>
>>>
>> +1k to the above!
>>
>> Thank you both for stepping up for this critical task.
>> Flavio
>>
>>
>>
>>> On Wed, Oct 19, 2016 at 3:50 PM, Jeremy Stanley 
>>> wrote:
>>>
>>> On 2016-10-18 22:22:28 + (+), Brian Rosmaita wrote:
 > Thus, the main point of this email is to propose Ian Cordasco and Erno
 > Kuvaja as new members of the Glance coresec team.  They've both been
 > Glance cores for several cycles, have a broad knowledge of the
 software
 > and team, contribute high-quality reviews, and are conversant with
 good
 > security practices.
 [...]

 Sounds good to me. From a VMT perspective, I'm just happy to see
 Glance keeping active participants with available bandwidth looking
 at prospective vulnerability reports so we can continue to churn
 through them faster and make them public sooner. Thanks for keeping
 the wheels turning!
 --
 Jeremy Stanley

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



>>>
>>> --
>>> SteveL
>>>
>>
>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> --
>> @flaper87
>> Flavio Percoco
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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-dev] [App-Catalog][Glare][Infra] Vm for app-catalog

[Mikhail Fedosin]

Hello folks!

Last week we released glare 0.1 and today they built a deb package for us -
now it's located in unstable repo https://packages.debian.
org/source/sid/glare with several dependencies from experimental.

Currently we can't deploy it on ubuntu, because 14.04 doesn't have all
required packages (like 'microversion-parse') and for 16.04 they are not
built yet. James Page promised everything will be available in 2-3 weeks,
but we can't wait for so long.

Now all other activities are done: we have working puppets, packages and
app-catalog code on review. For this reason I suggest to deploy staging vm
on debian sid, managed by openstack-infra, and let people test and play
with it. When ubuntu packages appear we will able to deploy ubuntu 16.04
immediately.

Best regards,
Mikhail Fedosin
__
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] [murano] [all] Ocata Design Summit - Proposed slot allocation

[Mikhail Fedosin]

Hey! If it's possible we could use one wr to discuss the integration of
Glare with Heat, Murano, Tacker and App-Catalog.

Best regards,
Mikhail Fedosin

On Thu, Sep 15, 2016 at 7:41 PM, Kirill Zaitsev <kzait...@mirantis.com>
wrote:

> Your email says, that in Murano we have:
> 1 fb 3wr
>
> This might be an error on my side, because I believe I’ve requested 1 fb
> 1wr in the questionnaire.
>
> I’m not really sure we’ll be able to utilize that much time (In Austin our
> 2d wr was just a bit too much to be honest) I’m asking to downgrade our
> slots to 1fb 1wr and suggest we spend the rest of our time on X-Project
> activities instead.
>
> I'd also ask to not overlap Murano and Community App Catalog sessions if
> that is possible.
>
> --
> Kirill Zaitsev
> Murano Project Tech Lead
> Software Engineer at
> Mirantis, Inc
>
> On 13 septembre 2016 at 11:50:35, Thierry Carrez (thie...@openstack.org)
> wrote:
>
> Murano: 1fb 3wr
>
>
> __
> 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] [Glare] IRC meeting time changed

[Mikhail Fedosin]

Hey! Since Glare became an independent project [1], we decided to change
the meeting time from Monday at 1730 UTC to biweekly one-hour meetings on
Thursdays 1600 UTC in #openstack-meeting [2] Please, add your topics to our
new agenda etherpad [3]!

Also, I have noticed that this meeting is not held for a long time [4][5]
and if Edgar Magana and other folks don't mind, we'll be able to organize a
weekly meeting for Glare.

Best,
Mike Fedosin

[1] https://github.com/openstack/glare
[2] https://review.openstack.org/#/c/365744/
[3] https://etherpad.openstack.org/p/glare-meeting-agenda
[4]
https://github.com/openstack-infra/irc-meetings/blob/master/meetings/doc-networking-team-meeting.yaml
[5] http://eavesdrop.openstack.org/meetings/networking_guide/2016/
__
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] [Glance][Glare] External locations design

[Mikhail Fedosin]

Thanks for you comments Stuart!

I also have some thoughts on this matter: first of all, I never liked how
locations are implemented in glance v2, and not just because of
inconsistencies in multiple locations per one image, but for the reason
that there are no differences between internal and external locations.
So, I think we're on right track with glare's implementation. But I suppose
we can improve it even more:  in my understanding, the service generally
does not work with external data. I will try to explain with an example:

Let's assume that we have a link to external ubuntu image (
http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-server-amd64.iso ). When
user adds this link to his image artifact, Glare doesn't validate it, it
just creates a blob instance in DB (optionally user may specify a checksum).
When user requests 'show' on his image, the blob url will look like this:
{"url": "http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-server-amd64.iso"},
and if user wants to download it, the image won't be proxied with glare -
it will be a direct download from ubuntu.com from the client.

In case of internal locations their urls are {"url":
"/artifacts/images//file"} and these downloads are done with
Glare as a proxy between the client and internal cloud storage, like Swift.

For compatibility, internal urls should work with external blobs as well,
but there will be a redirect to the external url:
"/artifacts/images//file" -> "
http://releases.ubuntu.com/16.04.1/ubuntu-16.04.1-server-amd64.iso;.

We can discuss it on the artifact meeting at 1730 UTC on Mondays at
#openstack-meeting-alt

Best,
Mike

On Tue, Aug 2, 2016 at 1:16 PM,  wrote:

> Hi Kairat,
>
> I think it's great to try and tease through the various issues here.
> I added some comments to the etherpad.
>
> -Stuart
>
> Hello all,
>>
>> I would like to start to describe some design decisions we made in Glare
>> code (https://review.openstack.org/#/q/topic:bp/glare-api+status:open).
>> If
>> you are not familiar with Glare I suggest you to read the following spec:
>>
>> https://github.com/openstack/glance-specs/blob/master/specs/
>> newton/approved/glance/glare-api.rst
>>
>> I hope it will help other folks to understand Glare approach and provide
>> some constructive feedback for Glare. I think that we can also use Glare
>> solution for Glance in near future to address some drawbacks we have in
>> Glance.
>>
>> Glare locations
>>
>> Glance and Glare have possibility to set some external url as
>> image(artifact) location. This feature is quite useful for users who would
>> like to refer to some external image or artifact (for example, Fedora
>> image
>> on official Fedora site) and not to store this image or artifact in the
>> cloud.
>>
>> External locations in Glance have several specialities:
>>
>>   1.
>>
>>   It is possible to setup multiple locations for an image. Glance uses
>>   special location strategy to define which location to use. This strategy
>>   defined in glance codebase and can be configured in glance conf.
>>   2.
>>
>>   Glance doesn?t differ image locations specified by url and image
>>   locations uploaded to Glance backend. Glance has some restrictions about
>>   which urls to use for locations (see Glance docs for more info).
>>
>>
>> Glare external locations designed in different way to address some
>> drawbacks we have in Glance. So the approach is the following:
>>
>>   1.
>>
>>   Glare doesn?t support multiple locations, you can specify dict of blobs
>>   in artifact type and add url for each blob in dict. User must define a
>>   name(f.e. region name or priority) for blob in dict and this name can be
>>   used to retrieve this blob from artifact. So decision about which
>> location
>>   to use will be outside of Glare.
>>   2.
>>
>>   Glare adds a special flag to database for external locations. So they
>>   will be treated differently in Glare when delete artifact. If blob
>> value is
>>   external url then we don?t need to pass this url to backend and just
>> delete
>>   the record in DB. For now, Glare allows only http(s) locations set but
>> it
>>   may be extended in future but the idea still the same: external location
>>   are just records in DB.
>>   3.
>>
>>   Glare saves blob size and checksum when specifying external url. When
>>   user specified url Glare downloads the blob by url, calculates its size
>> and
>>   checksum. Of course, it leads to some performance degradation but we can
>>   ensure that the external blob is immutable. We made this because
>> security
>>   seems more important for Glare than performance. Also there are plans to
>>   extend this approach to support subscriptions for external locations so
>> we
>>   can increase secureness of that operation.
>>
>>
>> I think that some of the features above can be implemented in Glance. For
>> example, we can treat our locations as only read-only links if external
>> flag will be implemented.  It will allow us to 

Re: [openstack-dev] [glare][kolla] timing of release of glare and request for technical interview on IRC wherever the glare team wants to have it

[Mikhail Fedosin]

Hello Steven!
Our plans for Glare in Newton are: 1. Implement beta version of
App-Catalog, based on Glare v1; 2. Develop an experimental support (POC)
for Murano, Heat and probably Tacker. It means that all big updates will be
in Ocata, and despite the fact that the code will be ready in this cycle, I
do not think we need an immediate adoption in Kolla.

And for sure, I'll be glad to answer all your questions, 1600 UTC today
works for me. So, let's meet at this time in your channel.

Best,
Mike

On Sat, Aug 6, 2016 at 2:21 PM, Steven Dake (stdake) 
wrote:

> Hey folks,
>
> I guess the split of glare and glance have been in the works for awhile.
> It is challenging for operational deployment managers (ODMs) such as Kolla
> to keep up with the internal goings-on of every big tent project (or
> projects that shave off from big-tent projects).  Just to be clear up
> front, the Kolla community doesn't care that glare split the work out.  The
> Kolla development team adapts very quickly to upstream changes.  What we do
> care about is that we present an accurate deployment for Newton that
> represents the best that OpenStack has to offer and offer a seamless
> operational experience – within Kolla's capacity constraints.
>
>  I need information on when the code base will be ready to consume (from a
> tarball on tarballs.oo).  Is this planned for milestone 3 – or post
> Newton?  I'd recommend post-Newton for the split to be consumable – it
> would ease the difficulty of adoption if the various ODMs (and Operators)
> had more then 3 weeks to work with on what is clearly a project required by
> every deployment based upon the threads I read.
>
> I have some other technical questions related to how the glance registry
> disappears (I believe this point was mentioned in another thread by Jay) as
> well as the upgrade mechanism (if any is needed) that would best be served
> by a high bandwidth conversation on IRC (and those conversations are
> recorded on eavesdrop for others to benefit).
>
> Would one of the technical cats from glare team drop by #opentack-kolla so
> we can get a quick (30 minutes) technical interview on the work to
> understand how this change impacts OpenStack in the short term (prior to
> Newton) and the long  term layout of the two projects so we can make a
> determination a to how to proceed technically?  I don't necessarily need to
> be there – any of our core reviewer team can handle the Q – but would
> like to be there if possible.
>
> If that doesn't work for the glare team, could we get 30 minutes of agenda
> time in what I'm sure is a busy glare team meeting to have the same
> technical discussion?
>
> If that doesn't work for the glare team, we can host the topic in the
> kolla team meeting (UTC1600 on Wednesdays) if a glare core reviewer or the
> glare PTL can stop by.
>
> Please let me know how you wish to proceed.
>
> TIA
> -steve
>
>
> __
> 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

Re: [openstack-dev] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Mikhail Fedosin]

Thank you all for your responses!

>From my side I can add that our separation is a deliberate step. We
pre-weighed all pros and cons and our final decision was that moving
forward as a new project is the lesser of two evils. Undoubtedly, in the
short term it will be painful, but I believe that in the long run Glare
will win.

Also, I want to say, that Glare was designed as an open project and we want
to build a good community with members from different companies. Glare
suppose to be a backend for Heat (and therefore TripleO), App-Catalog,
Tacker and definitely Nova. In addition we are considering the possibility
of storage Docker containers, which may be useful for Magnum.

Then, I think that comparison between Image API and Artifact API is not
correct. Moreover, in my opinion Image API imposes artificial constraints.
Just imagine that your file system can only store images in JPG format
(more precisely, it could store any data, but it is imperative that all
files must have the extension ".jpg"). Likewise Glance - I can put there
any data, it can be both packages and templates, as well as video from my
holiday. And this interface, though not ideal, may not work for all
services. But those artificial limitations that have been created, do
Glance uncomfortable even for storing images.

On the other hand Glare provides unified interface for all possible binary
data types. If we take the example with filesystem, in Glare's case it
supports all file extensions, folders, history of file changes on your
disk, data validation and conversion, import/export files from different
computers and so on. These features are not presented in Glance and I think
they never will, because of deficiencies in the architecture.

For this reason I think Glare's adoption is important and it will be a huge
step forward for OpenStack and the whole community.

Thanks again! If you want to support us, please vote for our talk on
Barcelona summit -
https://www.openstack.org/summit/barcelona-2016/vote-for-speakers/ Search
"Glare" and there will be our presentation.

Best,
Mike

On Fri, Aug 5, 2016 at 5:22 PM, Jonathan D. Proulx 
wrote:

>
> I don't have a strong opinion on the split vs stay discussion. It
> does seem there's been sustained if ineffective attempts to keep this
> together so I lean toward supporting the divorce.
>
> But let's not pretend there are no costs for this.
>
> On Thu, Aug 04, 2016 at 07:02:48PM -0400, Jay Pipes wrote:
> :On 08/04/2016 06:40 PM, Clint Byrum wrote:
>
> :>But, if I look at this from a user perspective, if I do want to use
> :>anything other than images as cloud artifacts, the story is pretty
> :>confusing.
> :
> :Actually, I beg to differ. A unified OpenStack Artifacts API,
> :long-term, will be more user-friendly and less confusing since a
> :single API can be used for various kinds of similar artifacts --
> :images, Heat templates, Tosca flows, Murano app manifests, maybe
> :Solum things, maybe eventually Nova flavor-like things, etc.
>
> The confusion is the current state of two API's, not having a future
> integrated API.
>
> Remember how well that served us with nova-network and neutron (né
> quantum).
>
> I also agree with Tim's point.  Yes if a new project is fully
> documented and integrated well into packaging and config management
> implementing it is trivial, but history again teaches this is a long
> road.
>
> It also means extra dev overhead to create and mange these
> supporting structures to hide the complexity from end users. Now if
> the two project are sufficiently different this may not be a
> significant delta as the new docs and config management code would be
> need in the old project if the new service stayed stayed there.
>
> -Jon
>
> __
> 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] [Glance][TC][Heat][App-Catalog][Murano][Tacker] Glare as a new Project

[Mikhail Fedosin]

Hi all,
after 6 months of Glare v1 API development we have decided to continue our
work in a separate project in the "openstack" namespace with its own core
team (me, Kairat Kushaev, Darja Shkhray and the original creator -
Alexander Tivelkov). We want to thank Glance community for their support
during the incubation period, valuable advice and suggestions - this time
was really productive for us. I believe that this step will allow the Glare
project to concentrate on feature development and move forward faster.
Having the independent service also removes inconsistencies in
understanding what Glance project is: it seems that a single project cannot
own two different APIs with partially overlapping functionality. So with
the separation of Glare into a new project, Glance may continue its work on
the OpenStack Images API, while Glare will become the reference
implementation of the new OpenStack Artifacts API.

Nevertheless, Glare team would like to continue to collaborate with the
Glance team in a new - cross-project - format. We still have lots in
common, both in code and usage scenarios, so we are looking forward for
fruitful work with the rest of the Glance team. Those of you guys who are
interested in Glare and the future of Artifacts API are also welcome to
join the Glare team: we have a lot of really exciting tasks and will always
welcome new members.
Meanwhile, despite the fact that my focus will be on the new project, I
will continue to be part of the Glance team and for sure I'm going to
contribute in Glance, because I am interested in this project and want to
help it be successful.

We'll have the formal patches pushed to project-config earlier next week,
appropriate repositories, wiki and launchpad space will be created soon as
well.  Our regular weekly IRC meeting remains intact: it is 17:30 UTC
Mondays in #openstack-meeting-alt, it will just become a Glare project
meeting instead of a Glare sub-team meeting. Please feel free to join!

Best regards,
Mikhail Fedosin

P.S. For those of you who may be curious on the project name. We'll still
be called "Glare", but since we are on our own now this acronym becomes
recursive: GLARE now stands for "GLare Artifact REpository" :)
__
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] [Glance][Heat][Horizon] Glance v2 and custom locations

[Mikhail Fedosin]

Hello!

As you may know glance v1 is going to be deprecated in Newton cycle. Almost
all projects support glance v2 at this moment, Nova uses it by default.
Only one thing that blocks us from complete adoption is a possibility to
set custom locations to images. In v1 any user can set a location to his
image, but in v2 this functionality is not allowed by default, which
prevents v2 adoption in services like Horizon or Heat.

It all happens because of differences between v1 and v2 locations. In v1 it
is pretty easy - user specifies an url and send a request, glance adds this
url to the image and activates it.
In v2 things are more complicated: v2 supports multiple locations per
image, which means that when user wants to download image file glance will
choose the best one from the list of locations. It leads to some
inconsistencies: user can add or delete locations from his image even if it
is active.

To enable adding custom locations operator has to set True to config option
'show_multiple_locations'. After that any user will be able to add or
remove his image locations, update locations metadata, and finally see
locations of all images even if they were uploaded to local storage. All
this things are not desired if glance v2 has public interface, because it
exposes inner cloud architecture. It leads to the fact that Heat and
Horizon and Nova in some cases and other services that used to set custom
locations in glance v1 won't be able to adopt glance v2. Unfortunately,
removing this behavior in v2 isn't easy, because it requires serious
architecture changes and breaks API. Moreover, many vendors use these
features in their clouds for private glance deployments and they really
won't like if we break anything.

So, I want to hear opinions from Glance community and other involved people.

Best regards,
Mikhail Fedosin
__
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] [Glare][Heat][Tacker][Murano][App-Catalog] How to validate your binary data in OpenStack

[Mikhail Fedosin]

Hello! Today I want to discuss with community one good feature in Glare -
artifact validation. In short Glare allows to validate binary data before
it's uploaded to store. For example, for Tosca we're able to check if
uploaded yaml is a valid template [1], for vm images we can test their
integrity. For sure, Glare supports quite sophisticated workflows, like
sending murano packages to external CI or validate Heat templates with
given environments.

So, I want to think out what validation is exactly required from Glare and
how we can help related projects to succeed, checking and reliably storing
their binary assets.

Best regards,
Mikhail Fedosin

[1]
https://review.openstack.org/#/c/337633/10/contrib/glare/openstack_app_catalog/artifacts.py@159
__
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] [Glare][Heat][TripleO] Heat artifact type

[Mikhail Fedosin]

On Wed, Jul 20, 2016 at 5:12 AM, Qiming Teng 
wrote:

> On Tue, Jul 19, 2016 at 06:44:06PM +0300, Oleksii Chuprykov wrote:
> > Hello!
> >
> > Today it was announced that Glare is ready for public review
> > http://lists.openstack.org/pipermail/openstack-dev/2016-July/099553.html
> So
> > we are ready to start working on integration Heat with Glare and
> > implementing a POC. After discussions with Glare team we see two design
> > options:
> >
> > 1) Create one artifact type that will contain template, nested templates
> > and environments.
> > Pros: It is easy to maintain integrity. Since artifact is immutable, we
> can
> > guarantee the consistency and prevent from accidentally removing of
> > dependent environment.
> > Cons: If we need to add new environments to use them with template, we
> need
> > to create new artifact.
> >
> > 2) Create 2 artifact types: environment and template.
> > Pros: It is easy to add new environments. You just need to create new
> > dependency from template artifact to environment one.
> > Cons: Some environment can be (mistakenly) removed, and template that
> have
> > dependencies on it will be in inconsistent state.
>
> Option 2 looks more flexible to me. I'm not sure we are encouraging
> users to introduce or rely on a hard dependency from a template to an
> environment file. With that, it is still good to know whether glare
> supports the concept of 'reference' where a referenced artifact cannot
> be deleted.
>

Hey!

Indeed, option 2 is more flexible, but in this case users have to manually
control dependencies, which is may be hard sometimes. Also, initially Glare
won't support 'hard' dependencies, this feature will be added in next
version, because it requires additional discussions. For this reason I
recommend option 1 and let Glare control template consistency for you, it
won't allow users to break anything.

Best,
Mike


>
>  - Qiming
>

> > So we want to hear your opinions and suggestions on the matter. Thanks in
> > advance!
> >
> > Best regards,
> > Oleksii Chuprykov
>
>
> __
> 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] [Glance][Heat][Murano][App-Catalog][Tacker] Glare is ready for wider review

[Mikhail Fedosin]

Hello! Today I'm happy to announce that Glare's code is done and the
service is ready for review [1].

Glare (from GLance Artifact REpository) is a new service in the Glance
project that provides a secure and customizable unified binary repository
for OpenStack [2].

The idea behind Glare is to allow various OpenStack services to catalog
different binary objects they use to operate. Images used by Nova to run
the VMs are just the best known examples of such objects; other examples
include Heat templates, Tacker blueprints, Murano packages, and so on.
Obviously, this functionality is common for different kinds of objects, and
is usually unrelated to the primary mission of respective projects using
these objects. That's why we implemented a dedicated service that will take
care of managing various data assets in OpenStack clouds.

This service fills a vacant niche in OpenStack and is intended to become a
unified catalog of structured meta-information, as well as related binary
data (with these objects comprising the 'artifacts'). In general Glare
provides next key functionality, it:
  * stores the objects reliably;
  * guarantees their immutability once they're stored;
  * provides search capabilities to find objects in the catalog;
  * controls access to the objects by enforcing usage and modification
policies, sharing and publication scenarios and so on;
  * returns the detailed info about the requested objects;
  * enables fetching of objects and manages their lifecycle;
  * supports import/export the objects between clouds.

Our next steps are related to help integrate various projects with Glare
and implement artifact types for them [3]. Currently we are working with
Heat, Murano and App-Catalog teams, but if you have any binary assets you
want to catalog reliably - feel free to contact me and we will help your
project to get the same functionality like Nova gets from Glance.

Links:
[1] Glare's code top commit: https://review.openstack.org/#/c/330459/5
[2] Merged Glare API spec: https://review.openstack.org/#/c/283136/
[3] Prototype of Heat artifact type:
https://review.openstack.org/#/c/292327/46/glance/objects/heat-templates.py

Best regards.
Mikhail Fedosin
__
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] [Glare] No meeting today - 07/04/2016

[Mikhail Fedosin]

Hi,

We’re cancelling team meeting today because a bunch of team members are on
holidays or won’t be able to attend.

Best regards,
Mikhail Fedosin
__
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] [nova][glance][qa] - Nova glance v2 work complete

[Mikhail Fedosin]

Hooray :) After a long period of time it's done. Thanks all who helped us
there!

Best regards,
Mike Fedosin

On Fri, Jun 10, 2016 at 3:27 PM, Kairat Kushaev 
wrote:

> \0/
> That's awesome.
> Big thanks to mfedosin and sudipto for driving this work.
>
> Best regards,
> Kairat Kushaev
>
> On Fri, Jun 10, 2016 at 2:52 PM, Monty Taylor 
> wrote:
>
>> On 06/10/2016 01:19 PM, Sean Dague wrote:
>> > On 06/07/2016 04:55 PM, Matt Riedemann wrote:
>> >> I tested the glance v2 stack (glance v1 disabled) using a devstack
>> >> change here:
>> >>
>> >> https://review.openstack.org/#/c/325322/
>> >>
>> >> Now that the changes are merged up through the base nova image proxy
>> and
>> >> the libvirt driver, and we just have hyper-v/xen driver changes for
>> that
>> >> series, we should look at gating on this configuration.
>> >>
>> >> I was originally thinking about adding a new job for this, but it's
>> >> probably better if we just change one of the existing integrated gate
>> >> jobs, like gate-tempest-dsvm-full or gate-tempest-dsvm-neutron-full.
>> >>
>> >> Does anyone have an issue with that? Glance v1 is deprecated and the
>> >> configuration option added to nova (use_glance_v1) defaults to True for
>> >> compat but is deprecated, and the Nova team plans to drop it's v1 proxy
>> >> code in Ocata. So it seems like changing config to use v2 in the gate
>> >> jobs should be a non-issue. We'd want to keep at least one integrated
>> >> gate job using glance v1 to make sure we don't regress anything there
>> in
>> >> Newton.
>> >
>> > use_glance_v1=False has now been merged as the default, so all jobs are
>> > now using glance v2 for the Nova <=> Glance communication -
>> > https://review.openstack.org/#/c/321551/
>> >
>> > Thanks to Mike and Sudipta for pushing this to completion.
>>
>> Congrats everybody!!!
>>
>>
>> __
>> 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-dev] [all][glare][api] How's going to use Glare?

[Mikhail Fedosin]

Hello! Some time ago we created new service called Glare that brings
support of artifacts in OpenStack. It is based on Glance v2 API and adapts
it to the possibility of using different artifact types, like containers,
various templates, application packages, but not just VM images only. You
can check these slides
https://docs.google.com/presentation/d/1WQoBenlp-0vD1t7mpPgQuepDmlPUXq2LOfRYnurZx74/edit#slide=id.p
and this presentation https://www.youtube.com/watch?v=XgpEdycRp9Y to learn
more about Glare and its mission.

We have been developing stable Glare version since February and today I'm
happy to present you the final specification of v1 API
https://review.openstack.org/#/c/283136/. Currently we work with Heat,
App-Catalog and Murano teams to implement features they need, but also I'll
be glad to get some feedback from other projects which are interested in
using Glare and catalogization their binaries.

Also it will be awesome if you can review the spec and leave your opinions
as well (it's kind of huge, but it's only because there are a lot of use
cases and examples of the API). There we tried to satisfy all API-WG,
DefCore and a common sense requirements to make this API as much RESTful as
possible.

Thanks in advance!

Best regards,
Mikhail Fedosin
__
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] [glance] [glare] [heat] [tosca] [tacker] [murano] [magnum] [app-catalog] Austin summit summary: Generic cataloging and Glare v1 API

[Mikhail Fedosin]

Hey! Thanks for this update.

If you ask me about FastTrack, frankly speaking I don't care how, but I
need Glare patches be reviewed (and merged ;) ) I think we reached some
agreement on the summit, that:
1. At first we will merge only most important things, so glance images
support won't be included - it reduces the amount of code.
2. Code will be split in small patches that easy to review.
3. Some architecture documentation with graphics will be available for
simplification
of understanding of Glare.

If it's not enough for core reviewers then we will have to develop some
mechanism how we can continue this work.

Best regards,
Mikhail Fedosin



On Wed, May 4, 2016 at 5:37 PM, Nikhil Komawar <nik.koma...@gmail.com>
wrote:

> Hi Bob,
>
> Thanks for reaching out!
>
> We're in the process of finalizing the API and the team is working hard on
> getting the code ready; atm with near to complete functionality WIP
> patches. Please be mindful of the fact that there is currently an
> experimental API in glance and code that will change completely. As we do
> not want to document these things, they are missing from the search results
> of advanced search engines.
>
> A good reference document is [1] . This spec has evolved over time and has
> input from many a standards so I do not expect drastic changes unless some
> security loophole is found during testing (Probability ~0.1).
>
> Hope that helps.
>
> [1] https://review.openstack.org/#/c/283136/
>
>
> On 5/4/16 10:08 AM, HADDLETON, Robert W (Bob) wrote:
>
> Hi Nikhil:
> The Tacker project may also be interested in using Glare during this
> cycle.  Is there any API or other documentation/examples that we could use
> to start?
>
> Thanks
>
> Bob
>
> On 5/3/2016 2:40 PM, EXT Nikhil Komawar wrote:
>
> Comment inline.
>
> On 5/3/16 3:21 PM, Flavio Percoco wrote:
>
> On 02/05/16 19:09 -0400, Nikhil Komawar wrote:
>
> Added a few more tags to the subject line.
>
>
>
> On 5/2/16 7:05 PM, Nikhil Komawar wrote:
>
> Hello everyone,
>
>
>
> Just wanted to send a brief summary of the discussions at the summit.
>
> This list is not holistic however, it covers the relevant aspects that
>
> various stakeholders need to be aware of.
>
>
>
>* Glare is useful for different use cases in OpenStack including
>
>  currently being asked for in Heat, Murano and TOSCA
>
>* Heat needs something for usage in Newton
>
>* Murano needs the stable API to adapt the changes as they currently
>
>  use experimental version
>
>* Glance team will continue to make progress on this effort and plan
>
>  to have POC after Newton R-16 [1]
>
>* The initial plan is to focus on base artifact (no data asset
>
>  associated) and then support at least one artifact type
>
>* The first artifact can be Murano application catalogs or Heat
>
>  templates depending on either team's priorities when Glare is ready
>
>  for consumption
>
>* In Newton, we will focus on the adoption of this service in at least
>
>  the above mentioned two projects and getting the API in good shape
>
>* Images compatibility is deferred for now
>
>* Glare will be a side-priority for Newton meaning most of the cores
>
>  are currently not expected to prioritize reviews on it except for
>
>  those who want to focus on cross project initiatives and those
>
>  involved in its adoption
>
>
> Does this mean there will be some sort of "Fast Track" again? I'm
> asking because
>
> No, we won't have the FastTrack model. But at the same time, we want to
> iterate over the code once that is consumed by the first service so that
> the behavioral changes found during that phase can be corrected before
> m-3. The end goal is to have a good API that can be consumed by other
> services (and something compliant with OpenStack standards).
>
> I believe this model polarizes the community a bit as far as picking
> reviews go.
>
> We voted to remove it in Mitaka and I was hoping we would workout a
> way to bring
>
> the community together in the Glare reviews.
>
> My goal is to have champions for each module that is being worked on in
> Newton (import, micro-versions, glare, documentation, etc) . This does
> have a little bit of effect in creating tribal knowledge but we do have
> that even today. The iterative plan though (yet to be formalized) is
> that we need some sort of knowledge sharing model. I have been trying to
> do that using the dedicated Glare meetings but we may need other models
> of KT (knowledge transfer) here.
>
>
>
> Please, don't get me wrong. As far as priorities go, I agr

Re: [openstack-dev] [Glance] Glare and future of artifacts in OpenStack.

[Mikhail Fedosin]

Hi! Thank you for you responses! I think I should be more precise here...

On Fri, Apr 22, 2016 at 6:10 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> Mike, thanks for the update. Very helpful. I did have a couple concerns,
> though, from the slides...
>
> 1) On Slide 8, you have a bullet point:
>
> "Quoting. We want to implement powerful nested quota support, rather than
> have one global quota config."
>
> I do not believe that Glare should have anything to do with quota support.
> The reason is because Glare doesn't actually own the process of consuming
> resources in the system. Glare simply describes some artifacts that are
> used in resource-consuming operations (like spawning an instance or
> spinning up a Heat stack).
>
> I don't believe it's necessary to place artificial limits on the number of
> metadata items that a particular artifact can have stored against it.
> Remember that rate-limiting != quota limits. Limiting the number of HTTP
> requests a user can make in a given time period to create metadata items on
> an artifact is something that should be handled by open source or
> commercial HTTP rate limiting solutions, not a quota handling solution.
>

There is a feature in glance_store, that it stores all data in one
container, owned by user 'glance'. In that case there is no possibility for
storage to distinguish the original owner of data. It means that we have to
support our own quota processing and calculate the allowed amount of data
before uploading it to the store.

Also it's a problem in Glance v2 that it confuses various quotas - allowed
number of tags, locations, members  and properties are checked along with
data size quoting:
https://github.com/openstack/glance/blob/master/glance/quota/__init__.py

In Glare we differentiate them, which means that allowed max number of some
artifact metadata (tags, members, etc.) are defined and checked with
oslo.versionobjects framework.
<http://www.lingvo-online.ru/ru/Search/Translate/GlossaryItemExtraInfo?text=%d1%80%d0%b0%d0%b7%d0%bb%d0%b8%d1%87%d0%b0%d1%82%d1%8c=distinguish=ru=en>

>
> 2) Also on Slide 8, you have:
>
> "Artifact sharing support. Should we implement 'community' visibility for
> artifacts or not? (will be discussed on the summit)."
>
> I won't be able to attend the summit session but I think the existing
> Glance visibility model (public, private and shared) is a good one and
> Glare should try to keep this model if they can.
>

I think that 'community' visibility is a good feature and there are real
use cases for that: too many public artifacts may confuse users. I think I
found a good solution how we can implement it right and I'll try to
formulate this and share the doc for future discussions. The whole idea is
to add conception of 'bookmarks' and allow users to bookmark only those
community artifacts that they need.

>
> 3) On Slide 9, you have this in "future work (in Newton)":
>
> "Tasks (asynchronous workflows) support."
>
> Please, please, please NO.
>
> There is absolutely no reason to couple a service that operates on
> artifacts in an asynchronous fashion with a service that provides metadata
> about those artifacts.
>
> It was a mistake to do this in Glance and it would be a mistake to do this
> in Glare. If you really want some async task processing function, create a
> totally separate service that does that. Don't put it in Glare.
>
> Flavio was right: no one wants to make it public, but having the support
of task engine may be useful.


> 4) On Slide 3 "Why Can't We Use Glance for This?", you list:
>
> "Complicated architecture, called Domain Model, that particularly prone to
> race conditions."
>
> Just want to say YES, you are spot on that the Domain proxy stuff made the
> code virtually unreadable and introduced too great a surface area for bugs.
> Great to see a move away from it.
>
> Thanks :)


> Best,
> -jay
>
> On 04/21/2016 12:47 PM, Mikhail Fedosin wrote:
>
>> Hello!
>>
>> Today I'm happy to present you a demo of a new service called Glare
>> (means GLance Artifact REpository)which will be used as a unified
>>
>> catalog of artifacts in OpenStack. This service appeared in Mitaka in
>> February and it succeeded Glance v3 API, that has become the
>> experimental version of Glare v0.1 API.
>> Currently we're working on stable v1 implementation and I believe it
>> will be available in Newton. Here I present a demo of stable Glare v1
>> and its features that are already implemented.
>>
>> The first video is a description of Glare service, its purposes, current
>> status and future development.
>> https://www.youtube.com/watch?v=XgpEdycRp9Y
>> Slides are located

[openstack-dev] [Glance] Glare and future of artifacts in OpenStack.

[Mikhail Fedosin]

Hello!

Today I'm happy to present you a demo of a new service called Glare (means
GLance Artifact REpository) which will be used as a unified catalog of
artifacts in OpenStack. This service appeared in Mitaka in February
and it succeeded
Glance v3 API, that has become the experimental version of Glare v0.1 API.
Currently we're working on stable v1 implementation and I believe it will
be available in Newton. Here I present a demo of stable Glare v1 and its
features that are already implemented.

The first video is a description of Glare service, its purposes, current
status and future development.
https://www.youtube.com/watch?v=XgpEdycRp9Y
Slides are located here:
https://docs.google.com/presentation/d/1WQoBenlp-0vD1t7mpPgQuepDmlPUXq2LOfRYnurZx74/edit#slide=id.p

Then it comes the demo. I have 3 videos that cover all basic features we
have at the moment:
1. Interaction with Glance and existing images. It may be useful for
App-Catalog when you import new image from it with Glare and use it through
Glance.
https://www.youtube.com/watch?v=flrlCpqwWzI

2. Sorting and filtering with Glare. Since Glare supports artifact
versioning in SemVer I present how user can sort and filter his images by
version with special range operators.
https://www.youtube.com/watch?v=ha3SLFZl_jw

3. Demonstration of Heat template artifact type and setting custom
locations for artifacts.
https://www.youtube.com/watch?v=EzEOJvKMUzo

We have dedicated Glare design session on Wednesday 27th of April at 2-40
PM. Will be glad if you may join us there.
https://www.openstack.org/summit/austin-2016/summit-schedule/events/9162?goback=1

Best regards,
Mikhail Fedosin
__
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] [nova] [glance] Getting the ball rolling on glance v2 in nova in newton cycle

[Mikhail Fedosin]

Hello! Thanks for bring this topic up.

First of all, as I mentioned before, the great work was done in Mitaka, so
Glance v2 adoption in Nova it is not a question of "if", and not even a
question of "when" (in Newton), but the question of "how".

There is a set of commits that make this trick:
1. Xen plugin
https://review.openstack.org/#/c/266933
Sean gave us several good suggestions how we can improve it. In short:

   - Make this only add new glance method calls *upload_vhd_glancev2 *
   *download_vhd_glancev2* which do the v2 work
   - Don't refactor existing code to do common code here, copy / paste /
   update instead. We want the final code to be optimized for v1 delete, not
   for v1 fixing (it was done in previous patchsets, but then I made the
   refactor to reduce the amount of code)

2. 'Show' image info
https://review.openstack.org/#/c/228578
Another 'schema-based' handler is added there. It transforms glance v2
image output to format adopted in nova.image.

We have to take in account that image properties in v1 are passed with http
headers which makes them case insensetive. In v2 image info is passed as
json document and 'MyProperty' and 'myproperty' are two different
properties. Thanks Brian Rosmaita who noticed it
http://lists.openstack.org/pipermail/openstack-dev/2016-February/087519.html

Also in v1 user can create custom properties like 'owner' or 'created_at'
and they are stored in special dictionary 'properties'. v2 images have flat
structure, which means that all custom properties are located on the same
level as base properties. It leads to the fact if v1 image has a custom
property that has name coincided with the name of base property, then this
property will be ignored in v2.

3. Listing of artifacts in v2 way
https://review.openstack.org/#/c/238309
There I added additional handlers that transforms v1 image filters in v2,
along with sorting parameters.

'download' and 'delete' patches are included in #238309 since they are
trivial

4. 'creating' and 'updating' images'
https://review.openstack.org/#/c/259097
<https://review.openstack.org/#/c/259097/18>
What were added there:

   - transformation to 2-stepped image creation (creation of instance in db
   + file uploading)
   - special handler for creation active images with size '0' without image
   data
   - the ability to set custom location for an image
   ('show_multiple_locations' option must be enabled in glance config for
   doing that)
   - special handler to remove custom properties from the image:
   purge_props flag in v1 vs. props_to_remove list in v2

What else has to be done:

   - Splitting in 2 patches is required: 'create' and 'update' to make it
   easier to review.
   - Matt suggested that it's better not to hardcode method logic for v1
   and v2 apis. But rather we should create a a common base class which is
   subclassed for v1/v2 specific callback (abstract) methods, and then we
   could have a factory that, given the version, provides the client impl
   we're going to deal with.

5. Also we have a bug: https://bugs.launchpad.net/nova/+bug/1539698
Thanks Samuel Matzek who found it. There is a fix
https://review.openstack.org/#/c/274203/ , but it has contradictory
opinions. If you can suggest a better solution, then I'll be happy :)


If you have any questions about how it was done feel free to send me emails
(mfedo...@mirantis.com) or ping me in IRC (mfedosin)

And finally I really want to thank you all for supporting this transition
to v2 - it's a big update for OpenStack and without community help it
cannot be done.

Best regards,
Mikhail Fedosin

<https://bugs.launchpad.net/nova/+bug/1539698>

On Wed, Apr 6, 2016 at 9:35 AM, Nikhil Komawar <nik.koma...@gmail.com>
wrote:

> Inline comment.
>
> On 4/1/16 10:16 AM, Sean Dague wrote:
> > On 04/01/2016 10:08 AM, Monty Taylor wrote:
> >> On 04/01/2016 08:45 AM, Sean Dague wrote:
> >>> The glance v2 work is currently blocked as there is no active spec,
> >>> would be great if someone from the glance team could get that rolling
> >>> again.
> >>>
> >>> I started digging back through the patches in detail to figure out if
> >>> there are some infrastructure bits we could get in early regardless.
> >>>
> >>> #1 - new methods for glance xenserver plugin
> >>>
> >>> Let's take a simplified approach on this patch -
> >>> https://review.openstack.org/#/c/266933 and only change the
> >>> xenapi/etc/xapi.d/plugins/ content in the following ways.
> >>>
> >>> - add upload/download_vhd_glance2 methods. Don't add an api parameter.
> >>> Add these methods mostly via copy/paste as we're optimizing for
> deleting
> >>> v1 not for fixing v1.
> >>>
> >>> That will put some infrastructure in p

Re: [openstack-dev] [defcore][glance] Glare not defcore ready

[Mikhail Fedosin]

Hi Flavio! Thank you for the clarification.

I do realize that I missed both meetings and that logs from one of them are
> not
> complete. I apologize if I've misinterpreted the intentions here. I do
> think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>

I want to tell you that the intention of the DefCore meeting was not to
confuse more on the work, rather it was to get clarity on all the
constraints that we are stuck with. Currently we intend to keep our focus
on interoperability issues this cycle - API hardening being our first
priority, along with early adoption from Murano and Community App Catalog.

And also I want to assure the community that Glare is being developed
consistent with the API WG principles and in such a way that it could be
included in DefCore at the appropriate time.

Best regards,
Mikhail Fedosin

On Fri, Apr 1, 2016 at 6:02 PM, Flavio Percoco <fla...@redhat.com> wrote:

> Greetings,
>
> I missed yday's Glance meeting but I went ahead and read the logs. While I
> was
> at it, I read a sentence from Erno (under the Glare updates topic) that
> caught
> my eye:
>
> 14:06:27  About that. I got couple of pings last night
> asking wtf is
> going on. Could we please stop selling Glare as replacement for
> Glance at
> least until we have a) stable API and b) some level of track
> record/testing
> that it actually is successfully working
>
> I went ahead and looked for the defcore meeting logs[0] (btw, seems like
> the bot
> died during the meeting) to get a better understanding of what Erno meant
> (I
> assumed the pings he mentioned came from the meeting and then confirmed
> it).
>
> From the small piece of conversation I could read, and based on the current
> status of development, priorities and support, I noticed a few "issues"
> that I
> believe are worth raising:
>
> 1. Glare's API is under discussion and it's a complementary service for
> Glance.
> [1] 2. Glare should not be a required API for every cloud, whereas Glance
> is and
> it should be kept that way for now. 3. Glare is not a drop-in replacement
> for
> Glance and it'll need way more discussions before that can happen.
>
> I do realize that I missed both meetings and that logs from one of them
> are not
> complete. I apologize if I've misinterpreted the intentions here. I do
> think
> engaiging with DefCore as early in the process as possible is good but I'd
> also
> like to clarify the intentions here before this escalates (again) into more
> confusion about what Glance's future looks like.
>
> So, to summarize, I don't think Glare should be added in DefCore in the
> near
> future. The Glance team should focus on fixing the current interoperability
> issues before we'll be able to actually try to build on top of the current
> API.
>
> Hope the above makes sense,
> Flavio
>
> [0]
> http://eavesdrop.openstack.org/meetings/defcore/2016/defcore.2016-03-30-16.00.log.txt
> [1] https://review.openstack.org/#/c/283136
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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

Re: [openstack-dev] [Glance][Artifacts] Current status of Glance artifacts

[Mikhail Fedosin]

Hi! Thank you for your interest in Glare. I'm leading this project and I'll
try to answer your questions :)

Glare is a new service under Glance repo which previously was called Glance
v3, now it's experimental Glare v0.1 api. It has a devstack support, so you
can deploy it with setting ENABLED_SERVICES=g-glare in your localrc file.
At the moment only Murano uses v0.1 as an optional backend for its
packages, but in common case it's not recommended for real deployments.

While we were working on the service we got a lot of advice and suggestions
from community and API-WG about how we can improve our api. We collected
them all and started implementing stable Glare api - v1 [1]. Currently
stable Glare is under active development, skeleton is almost here [2] and I
think we can organize public POC demo next week (it will be announced later
on Friday). More details and functionality will be presented on Newton
summit.

Our plan is stabilize Glare as much as possible and merge it in Newton.
Then in Ocata add Glare's v1 support in Nova and other services like Heat,
Sahara, App Catalog, Tacker, Murano, Mistral and so on.

If you have any other questions you can ask here or visit our weekly irc
meeting on Monday at 1730 UTC in #openstack-meeting-alt [3].

Best regards,
Mikhail Fedosin

[1] https://review.openstack.org/#/c/283136/
[2] https://review.openstack.org/#/c/292327/
[3]
https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda

On Tue, Mar 15, 2016 at 3:12 AM, Ramakrishna, Deepti <
deepti.ramakris...@intel.com> wrote:

> Hi all,
>
> I have some questions around the current status of Artifacts (Glare) in
> Glance.
>
> 1. From briefly poking around, I found [1] to be the most current BP for
> implementing artifacts. I see few work items like declarative definitions
> of artifact types, adding database layer, plugins loader etc (I assume all
> the work items which makes this feature alive) have already been merged.
> But for other patches like [2] which is meant for adding Glare client has
> been on hold until there is a better understanding of Glare APIs. I also
> see from Mitaka mid-cycle meetup [3] that there were few artifact tasks
> which were missed out for Mitaka and some more Glare API discussions
> planned targeting Newton.
> Where can I find the *exact* list of work items and their ETAs?
>
> 2. Is it production ready? Is there any service using artifacts right now?
> I did see a response to this question here [4] where Alexander mentioned
> that "Murano stores its packages in Glance since the Liberty release. There
> is a plan to create a plugin for Heat packages, but the Heat team has
> decided to wait till the API is stable (this should happen during the
> Mitaka cycle)". How stable are these APIs now as we are approaching the end
> of Mitaka cycle?
>
> Sorry for being naïve since I am just a day old to Glare :)
>
> Thanks,
> Deepti
>
> [1] https://blueprints.launchpad.net/glance/+spec/artifact-repository
> [2] https://review.openstack.org/#/c/255220/
> [3] https://etherpad.openstack.org/p/glance-mitaka-virtual-mid-cycle
> [4]
> https://www.mirantis.com/blog/glance-api-v3-and-the-openstack-community-app-catalog/
>
> __
> 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][Glance]Glance v2 api support in Nova

[Mikhail Fedosin]

Hello!

In late December I wrote several messages about glance v2 support in Nova
and Nova's xen plugin. Many things have been done after that and now I'm
happy to announce that there we have a set of commits that makes Nova fully
v2 compatible (xen plugin works too)!

Here's the link to the top commit https://review.openstack.org/#/c/259097/
Here's the link to approved spec for Mitaka
https://github.com/openstack/nova-specs/blob/master/specs/mitaka/approved/use-glance-v2-api.rst

I think it'll be a big step for OpenStack, because api v2 is much more
stable and RESTful than v1.  We would very much like to deprecate v1 at
some point. v2 is 'Current' since Juno, and after that there we've had a
lot of attempts to adopt it in Nova, and every time it was postponed to
next release cycle.

Unfortunately, it may not happen this time - this work was marked as
'non-priority' when the related patches had been done. I think it's a big
omission, because this work is essential for all OpenStack, and it will be
a shame if we won't be able to land it in Mitaka.
As far as I know, Feature Freeze will be announced on March, 3rd, and we
still have enough time and people to test it before. All patches are split
into small commits (100 LOC max), so they should be relatively easy to
review.

I wonder if Nova community members may change their decision and unblock
this patches? Thanks in advance!

Best regards,
Mikhail Fedosin
__
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] [heat-translator][tacker] Openstack Artifact Repository

[Mikhail Fedosin]

Hello Bruce! So glad to hear it!

Just want to inform you that soon artifacts will be a standalone service
under openstack/glance repo. The service will be called Glare (GLance
Artifact REpository).

We really want to see you involved! There is a weekly meeting that is held
on Mondays at 5PM UTC in #openstack-meeting-alt
https://etherpad.openstack.org/p/glance-artifacts-sub-team-meeting-agenda
There we can discuss all things you need.

Thanks for looking at Glare!

Best regards,
Mikhail Fedosin
__
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] [glance] Glance Core team additions/removals

[Mikhail Fedosin]

I'm always happy to add new cores :)

+1 for Kairat. He has been working really hard and the huge number of
high-quality reviews and commits is a good proof of this. Welcome Kairat!

+1 for Brian. He is one of the most experienced technical specialists and he's
a well-known member in the community. So, I was wondering why he was not a
core yet (better late than never).

+1 for leaving Fei Long in core team. Please! Moreover we can change IRC
meeting time to more comfortable for his tz - 3 AM is overkill.

Alex now in Murano and unfortunately he won't be able to participate in
Glance initiatives in the near future. But hope he will be back!

On Wed, Jan 27, 2016 at 10:38 AM, 见习骑士 <491745...@qq.com> wrote:

> Hi All,
>
> +1 for Kairat. He has really done a lot of work both in reviews and
> commits.
> Personally say, he helped me a lot with my patches as well. Thanks!
>
> +1 for Brian. As I know, he has done great job in glance-specs review,
> especially the image-import-refactor which is the most important goal in
> Mitaka.
>
> +1 for Fei Long. We have discussed a lot about DB-based quota blueprint
> which is maybe a big work to do. In my sight, he still want to help us to
> make Glance better.
> And as he said, he will balance his time. Hope he could stay.
>
> Cheers,
> WangXiyuan
>
> -- Original --
> *From: * "Fei Long Wang";;
> *Date: * Wed, Jan 27, 2016 05:34 AM
> *To: * "openstack-dev";
> *Subject: * Re: [openstack-dev] [glance] Glance Core team
> additions/removals
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi team,
>
> As you know, I'm working on Zaqar team as PTL in Mitaka and it's a
> time-consuming work. So my focus shifted for a bit but I'm now trying to
> balance my time. I'd rather stay in the team if there is still space :)
> Thanks.
>
> My recent code review:
> http://stackalytics.com/report/contribution/glance-group/30
> Glance DB-based quota: https://review.openstack.org/27
>
>
> On 27/01/16 03:41, Flavio Percoco wrote:
> >
> > Greetings,
> >
> > I'd like us to have one more core cleanup for this cycle:
> >
> > Additions:
> >
> > - Kairat Kushaev
> > - Brian Rosmaita
> >
> > Both have done amazing reviews either on specs or code and I think they
> both
> > would be an awesome addition to the Glance team.
> >
> > Removals:
> >
> > - Alexander Tivelkov
> > - Fei Long Wang
> >
> > Fei Long and Alexander are both part of the OpenStack community.
> However, their
> > focus and time has shifted from Glance and, as it stands right now, it
> would
> > make sense to have them both removed from the core team. This is not
> related to
> > their reviews per-se but just prioritization. I'd like to thank both,
> Alexander
> > and Fei Long, for their amazing contributions to the team. If you guys
> want to
> > come back to Glance, please, do ask. I'm sure the team will be happy to
> have you
> > on board again.
> >
> > To all other members of the community. Please, provide your feedback.
> Unless
> > someone objects, the above will be effective next Tuesday.
> >
> > Cheers,
> > Flavio
> >
> >
> >
> >
> __
> > 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
>
> - --
> Cheers & Best regards,
> Fei Long Wang (???)
> -
> --
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flw...@catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> -
> --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJWp+ZOAAoJEOshLRZu+ElUhwgH/RISV2JuhKCsBWKePexBLO5s
> uNVLqyRzHYknCG+5nZ8CZMw1YglRe5WtiiyDTSaapHf2dUQmEsp9eXkU/3hjxeS+
> uS4lpeqCg1c7PQKSZTfnk53XDNVj5dZMtNnYlV3iZ0TDuPRC7kK+5vD8dCgz38hj
> C1+0girlMgMoXxx6/rJxRvtVrxxfTKcZK37ttrQkjZIxKhofMEHdFqIRj3j1EDOc
> KsSed/UNqe3QSi0kb8eGiXN39MoxfbA326AcAzHPg+7doYIyzIkiJQHwlC6t0s/z
> 4iILWcqZ1W6RCtux8S37GkowVP5cPq6WKfy2hwCgoowa4dB+tKetdjkD3IKSsVc=
> =1+am
> -END 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
>
>
__
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] [Nova][Glance] Nova + Glance_v2 = Love

[Mikhail Fedosin]

Sam, Flavio, Zhenyu, Daniel thank you for your responses!

Indeed, we're in a difficult position with activating zero-size images...
To fix it we have to solve 2 problems: one with disk and container formats
parameters - glance v2 doesn't allow activate images if these two are
unset; and the second with image data - glance v2 requires some data to be
passed before image activation.

About formats: I don't see any good solution rather than to hardcode them
for Glance and then ignore in Nova. If you can figure out a better one,
please share :) But changing image schema - no way!

About data: afaiu, block_device_mapping property contains volume_id. That
means we may take it out and activate an image by providing new location,
i.e. cinder://volume_id. The problem is setting custom locations for image
is disabled by default and enabling it may cause serious mishaps.
My solution was to provide empty data (not 1 byte as Sam said) with
image-upload, it leads to image activation and it works. Unfortunately,
it's just another workaround, because we create absolutely unnecessary
empty file in store and after that users can download it, which is wrong.
But we can improve it on glance side: if we provide empty data in
image-upload, glance won't create a file in store and set location to the
image (in other words - avoid Location layer in Glance domain model). In
that case these operation will be identical (v1:image-create(size=0) and
v2:image-create()+image-upload(data='')).

Frankly speaking I wish to see more feedback on this matter, because we
will have to make difficult decisions or Nova will never adopt Glance v2
api.

On Fri, Jan 8, 2016 at 10:14 PM, Sam Matzek <matzek...@gmail.com> wrote:

> On Fri, Jan 8, 2016 at 11:54 AM, Sam Matzek <matzek...@gmail.com> wrote:
> > On Fri, Jan 8, 2016 at 8:31 AM, Flavio Percoco <fla...@redhat.com>
> wrote:
> >> On 29/12/15 07:41 -0600, Sam Matzek wrote:
> >>>
> >>> On Thu, Dec 24, 2015 at 7:49 AM, Mikhail Fedosin <
> mfedo...@mirantis.com>
> >>> wrote:
> >>>>
> >>>> Hello, it's another topic about glance v2 adoption in Nova, but it's
> >>>> different from the others. I want to declare that there is a set of
> >>>> commits,
> >>>> that make Nova version agnostic and allow to work with both glance
> apis.
> >>>> The
> >>>> idea of the solution is to determine the current api version in the
> >>>> beginning and make appropriate requests after.
> >>>> (https://review.openstack.org/#/c/228578/,
> >>>> https://review.openstack.org/#/c/238309/,
> >>>> https://review.openstack.org/#/c/259097/)
> >>>>
> >>>> Indeed, it requires some additional (and painful) work, but now all
> >>>> tempest
> >>>> tests pass in Jenkins.
> >>>>
> >>>> Note: this thread is not about xenplugin, there is another topic,
> called
> >>>> 'Xenplugin + Glance_v2 = Hate'
> >>>>
> >>>> Here the main issues we faced and how we've solved them:
> >>>>
> >>>> 1. "changes-since" filter for image-list is not supported in v2 api.
> >>>> Steve
> >>>> Lewis made a great job and implemented a set of filters with
> comparison
> >>>> operators https://review.openstack.org/#/c/197388/. Filtering by
> >>>> 'changes-since' is completely similar to 'gte:updated_at'.
> >>>>
> >>>> 2. Filtering by custom properties must have prefix 'property-'. In v2
> >>>> it's
> >>>> not required.
> >>>>
> >>>> 3. V2 states that all custom properties must be image attributes, but
> >>>> Nova
> >>>> assumes that they are included in 'properties' dictionary. It's fixed
> >>>> with
> >>>> glanceclient's method 'is_base_property(prop_name)', that returns
> False
> >>>> in
> >>>> case of custom property.
> >>>>
> >>>> 4. is_public=True/False is visibility="public"/"private" respectively.
> >>>>
> >>>> 5. Deleting custom image properties in Nova is performed with
> >>>> 'purge_props'
> >>>> flag. If it's set to True, then all prop names, that are not included
> in
> >>>> updated data, will be removed. In case of v2 we have to explicitly
> >>>> specify
> >>>> prop names in the list param 'remove_props'. To implement this
> behaviour,
> >>>> if
> >>>> 'purge_props' is set, we make additional 'get' requ

[openstack-dev] [Nova][Glance] Nova + Glance_v2 = Love

[Mikhail Fedosin]

Hello, it's another topic about glance v2 adoption in Nova, but it's
different from the others. I want to declare that there is a set of
commits, that make Nova version agnostic and allow to work with both glance
apis. The idea of the solution is to determine the current api version in
the beginning and make appropriate requests after.
(https://review.openstack.org/#/c/228578/,
https://review.openstack.org/#/c/238309/,
https://review.openstack.org/#/c/259097/)

Indeed, it requires some additional (and painful) work, but now all tempest
tests pass in Jenkins.

Note: this thread is not about xenplugin, there is another topic, called
'Xenplugin + Glance_v2 = Hate'

Here the main issues we faced and how we've solved them:

1. "changes-since" filter for image-list is not supported in v2 api. Steve
Lewis made a great job and implemented a set of filters with comparison
operators https://review.openstack.org/#/c/197388/. Filtering by
'changes-since' is completely similar to 'gte:updated_at'.

2. Filtering by custom properties must have prefix 'property-'. In v2 it's
not required.

3. V2 states that all custom properties must be image attributes, but Nova
assumes that they are included in 'properties' dictionary. It's fixed with
glanceclient's method 'is_base_property(prop_name)', that returns False in
case of custom property.

4. is_public=True/False is visibility="public"/"private" respectively.

5. Deleting custom image properties in Nova is performed with 'purge_props'
flag. If it's set to True, then all prop names, that are not included in
updated data, will be removed. In case of v2 we have to explicitly specify
prop names in the list param 'remove_props'. To implement this behaviour,
if 'purge_props' is set, we make additional 'get' request to determine the
existing properties and put in 'remove_prop' list only those, that are not
in updated_data.

6. My favourite:
There is an ability to activate an empty image by just providing 'size =
0': https://review.openstack.org/#/c/9715/, in this case image will be a
collection of metadata. Glance v2 doesn't support this "feature" and that's
why we have to implement a very dirty workaround:
* v2 requires, that disk_format and container-format must be set before
the activation. if these params are not provided to 'create' method then we
hardcode it to 'qcow2' and 'bare'.
* we call 'upload' method with empty data (data = '') to activate image.
Me (and the rest glance team) think that this image activation with
zero-size is inconsistent and we won't implement it in v2. So, I'm going to
ask if Nova really needs this feature and maybe it's possible to make it
work without it.

In conclusion, I want to congratulate you with this huge progress and say
there is a big chance that we can deprecate glance v1 in Mitaka cycle.

Hooray!
And Merry Christmas!

--
Best regards,
Mikhail Fedosin
__
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][Glance] Xenplugin + Glance_v2 = Hate

[Mikhail Fedosin]

Hello! As you may know there is a big initiative to adopt glance v2 api in
Nova and the important part is making related changes in xenglugin.
Unfortunately xenplugin doesn't use neither nova.image api nor
glanceclient. Instead of this it has own http client implementation and
bunch of hardcoded 'v1' urls (example,
https://github.com/openstack/nova/blob/master/plugins/xenserver/xenapi/etc/xapi.d/plugins/glance#L130).
It leads to the fact, that it will be really hard to switch it on v2 api
right.

Personally I see 2 solutions:
1. Make xenplugin to adopt nova.image api, which will make it
version-agnostic. Here it's not easy to implement and we won't be able to
keep backward compatibility with the existing lowlevel code.
2. Also hardcode v2 urls on par with v1 and do the same thing as in
nova.image - to determine current glance api version before request and
then use appropriate urls in methods.

IMHO, the second solution is more preferable, because I understand how to
do it and the v1/v2 compatibility will be 100%. It guarantees that we won't
break any of existing deployments and it will allow to merge glance_v2 code
in nova.image much quicker.

All opinions and advice will be very helpful. Thanks in advance!

--
Best regards,
Mikhail Fedosin
__
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] [glance] Add Ian Cordasco back into glance-core

[Mikhail Fedosin]

+1

Hooray! Welcome back :)
On Dec 8, 2015 18:32,  wrote:

> +1
>
> I'm delighted to hear this.
>
> Welcome back Ian.
>
>
>> +1 from me!  Glad to have Ian back.
>>
>> On 12/7/15, 11:36 AM, "Flavio Percoco"  wrote:
>>
>> > Greetings,
>> > > Not long ago, Ian Cordasco, sent an email out stepping down from his
>> > core roles as he didn't have the time to dedicate to the project
>> > team's he was part of.
>> > > Ian has contacted me mentioning that he's gotten clearance, and
>> > therefore, time to dedicate to Glance and other activities around our
>> > community (I'll let him expand on this and answer questions if there
>> > are).
>> > > As it was mentioned in the "goodbye thread" - and because Ian knows
>> > Glance quite well already, including the processes we follow - I'd
>> > like to propose a fast-track addition for him to join the team again.
>> > > Please, just like for every other folk volunteering for this role, do
>> > provide your feedback on this. If no rejections are made, I'll proceed
>> > to adding Ian back to our core team in a week from now.
>> > > Cheers,
>> > Flavio
>> > > --
>> > @flaper87
>> > Flavio Percoco
>>
>>
>>
>>
>>
> __
> 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] [Infra] Remove .mailmap files from OpenStack repos

[Mikhail Fedosin]

Currently we have .mailmap files in the root of almost all OpenStack repos:
https://github.com/openstack/glance/blob/master/.mailmap
https://github.com/openstack/horizon/blob/master/.mailmap
https://github.com/openstack/nova/blob/master/.mailmap
https://github.com/openstack/cinder/blob/master/.mailmap
etc.

But it seems that they're very outdated (last time many of them were
updated about 2 years ago). So, do we still need these files or it's better
to remove them?

--
Best regards,
Mikhail Fedosin
__
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] [stable][glance] glance-stable-maint group refresher

[Mikhail Fedosin]

Thank you for your confidence in me folks! I I'll be happy to maintain the
stability of our project and continue working on its improvements.

Best regards,
Mike

On Wed, Sep 30, 2015 at 4:28 PM, Nikhil Komawar 
wrote:

>
>
> On 9/30/15 8:46 AM, Kuvaja, Erno wrote:
>
> Hi all,
>
>
>
> I’d like to propose following changes to glance-stable-maint team:
>
> 1)  Removing Zhi Yan Liu from the group; unfortunately he has moved
> on to other ventures and is not actively participating our operations
> anymore.
>
> +1 (always welcome back)
>
> 2)  Adding Mike Fedosin to the group; Mike has been reviewing and
> backporting patches to glance stable branches and is working with the right
> mindset. I think he would be great addition to share the workload around.
>
> +1 (definitely)
>
>
>
> Best,
>
> Erno (jokke_) Kuvaja
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
>
> Thanks,
> Nikhil
>
>
> __
> 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

Re: [openstack-dev] [Glance] glance core rotation part 1

[Mikhail Fedosin]

+1.
I hope that Zhi Yan joined Alibaba to make it use Openstack in the future :)

On Mon, Sep 14, 2015 at 11:23 AM, Kuvaja, Erno  wrote:

> +1
>
>
>
> *From:* Alex Meade [mailto:mr.alex.me...@gmail.com]
> *Sent:* Friday, September 11, 2015 7:37 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Glance] glance core rotation part 1
>
>
>
> +1
>
>
>
> On Fri, Sep 11, 2015 at 2:33 PM, Ian Cordasco 
> wrote:
>
>
>
> -Original Message-
> From: Nikhil Komawar 
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: September 11, 2015 at 09:30:23
> To: openstack-dev@lists.openstack.org 
> Subject:  [openstack-dev] [Glance] glance core rotation part 1
>
> > Hi,
> >
> > I would like to propose the following removals from glance-core based on
> > the simple criterion of inactivity/limited activity for a long period (2
> > cycles or more) of time:
> >
> > Alex Meade
> > Arnaud Legendre
> > Mark Washenberger
> > Iccha Sethi
>
> I think these are overdue
>
> > Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)
>
> Sad to see Zhi Yan Liu's activity drop off.
>
> > Please vote +1 or -1 and we will decide by Monday EOD PT.
>
> +1
>
> --
> Ian Cordasco
>
> __
> 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

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Mikhail Fedosin]

Both options are good, it's a little better at 1500 UTC.
+1 consistent time.

On Fri, Mar 13, 2015 at 9:23 PM, Steve Lewis steve.le...@rackspace.com
wrote:

 +1 consistent time

 +1 for 1500 UTC since that has come up.

 On 09/03/15 09:07, Nikhil Komawar wrote:
 
 So, the new proposal is:
 Glance meetings [1] to be conducted
 weekly on
 Thursdays at 1400UTC [2] on
 #openstack-meeting-4

 __
 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

Re: [openstack-dev] [Glance] Core nominations.

[Mikhail Fedosin]

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.

2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com:

 -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 the PTL. This is
  typically due to a drop off of involvement by the member such that
  they are no longer meeting expectations to maintain team
  membership. https://wiki.openstack.org/wiki/NeutronCore The PTL
  may remove a member from neutron-core at any time. Typically when a
  member has decreased their involvement with the project through a
  drop in reviews and participation in general project development,
  the PTL will propose their removal and remove them. Members who
  have previously been core may be fast-tracked back into core if
  their involvement picks back up So, as Louis has mentioned, it's a
  routine work, and why should we be any different? Also, I suggest
  to write the same wiki document for Glance to prevent these issues
  in the future.
 

 Does the rule belong to e.g. governance repo? It seems like a sane
 requirement for core *reviewers* to actually review code, no? Or are
 there any projects that would not like to adopt such a rule formally?

 /Ihar
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05
 rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH
 g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI
 lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz
 E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD
 1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o=
 =lcLY
 -END 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

__
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] [Glance] Core nominations.

[Mikhail Fedosin]

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 longer meeting expectations to maintain team membership.
https://wiki.openstack.org/wiki/NeutronCore
The PTL may remove a member from neutron-core at any time. Typically when
a member has decreased their involvement with the project through a drop in
reviews and participation in general project development, the PTL will
propose their removal and remove them. Members who have previously been
core may be fast-tracked back into core if their involvement picks back up
So, as Louis has mentioned, it's a routine work, and why should we be any
different?
Also, I suggest to write the same wiki document for Glance to prevent these
issues in the future.

Best, Mike

2015-03-05 12:31 GMT+03:00 Thierry Carrez thie...@openstack.org:

 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* easy to add back long-inactive members if they
 happen to come back.

 Again, core is not a badge, it corresponds to a set of duties. If some
 people don't fill those duties anymore, it's better to remove them than
 to keep them around: it maintains the standards of expected review
 activity fore core reviewers at a high level.

 --
 Thierry Carrez (ttx)


 __
 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