[openstack-dev] [mogan] Transitioning PTL role to Li Tao

[Zhenguo Niu]

Hi team,

Due to my job responsibilities changed a while ago, I will transition the
PTL role to Li Tao.

If anyone has any concerns with this, please reach out to me.

-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Adds ability to create bare metal servers without an OS

[Zhenguo Niu]

Hi folks!

We plan to add a new no-OS option [1] for users who wants to run a
proprietary, externally licensed, or customized operating system on a bare
metal server.

A bare metal server with no operating system can be set up to boot and load
the OS from a PXE setup. For this to work properly, the PXE setup needs to
be in the same tenant network with the bare metal server, that is to say,
users need to create a VM or bare metal instance with existing OS for PXE
setup and maybe also some unique installation tools/scripts.

This new option streamlines the deployment process and eliminates
installation of the unnecessary operating system. A spec for this will be
proposed soon, if you are interested, please help to give some suggestions
there then, thanks!


[1] https://blueprints.launchpad.net/mogan/+spec/no-os-server

-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Weekly meeting canceled next week

[Zhenguo Niu]

Hello team,

I'll cancel next week's IRC meeting due to China's National Day holiday.

Happy Golden Week!

-- 
Best Regards,
Zhenguo Niu
__
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] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

I have proposed http://forumtopics.openstack.org/cfp/details/33 and will be
present. Thanks Thierry!

On Thu, Sep 28, 2017 at 9:48 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Erik McCormick wrote:
> > [...]
> > Also, if you'd like to discuss this in detail with a room full of
> > bodies, I suggest proposing a session for the Forum in Sydney. If some
> > of the contributors will be there, it would be a good opportunity for
> > you to get feedback.
>
> Yes, "Bare metal as a service: Ironic vs. Mogan vs. Nova" would make a
> great topic for discussion in Sydney, assuming Zhenguo is able to make
> the trip... Discussing the user need on one side, and how to best
> integrate with the existing pieces on the other side would really help
> starting this on the right foot.
>
> Zhenguo: if you plan to be present, could you suggest this topic for
> discussion at: http://forumtopics.openstack.org/
>
> Deadline is tomorrow :)
>
> --
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

Thanks Thierry, not sure if I can make the trip, but will have a try :)

On Thu, Sep 28, 2017 at 9:48 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Erik McCormick wrote:
> > [...]
> > Also, if you'd like to discuss this in detail with a room full of
> > bodies, I suggest proposing a session for the Forum in Sydney. If some
> > of the contributors will be there, it would be a good opportunity for
> > you to get feedback.
>
> Yes, "Bare metal as a service: Ironic vs. Mogan vs. Nova" would make a
> great topic for discussion in Sydney, assuming Zhenguo is able to make
> the trip... Discussing the user need on one side, and how to best
> integrate with the existing pieces on the other side would really help
> starting this on the right foot.
>
> Zhenguo: if you plan to be present, could you suggest this topic for
> discussion at: http://forumtopics.openstack.org/
>
> Deadline is tomorrow :)
>
> --
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

Thanks Sean for raising the concerns. We don't really fork nova but some
parts of the "ABI" of it. For the 2 API surfaces, we have different
strategies, please see explanations below:

On Wed, Sep 27, 2017 at 10:34 PM, Sean Dague <s...@dague.net> wrote:

> On 09/27/2017 09:31 AM, Julia Kreger wrote:
> > [...]
> >>> The short explanation which clicked for me (granted it's probably an
> >>> oversimplification, but still) was this: Ironic provides an admin
> >>> API for managing bare metal resources, while Mogan gives you a user
> >>> API (suitable for public cloud use cases) to your Ironic backend. I
> >>> suppose it could have been implemented in Ironic, but implementing
> >>> it separately allows Ironic to be agnostic to multiple user
> >>> frontends and also frees the Ironic team up from having to take on
> >>> yet more work directly.
> >>
> >>
> >> ditto!
> >>
> >> I had a similar question at the PTG and this was the answer that
> convinced
> >> be
> >> may be worth the effort.
> >>
> >> Flavio
> >>
> >
> > For Ironic, the question did come at the PTG up of tenant aware
> > scheduling of owned hardware, as in Customer A and B are managed by
> > the same ironic, only customer A's users should be able to schedule on
> > to Customer A's hardware, with API access control restrictions such
> > that specific customer can take action on their own hardware.
> >
> > If we go down the path of supporting such views/logic, it could become
> > a massive undertaking for Ironic, so there is absolutely a plus to
> > something doing much of that for Ironic. Personally, I think Mogan is
> > a good direction to continue to explore. That being said, we should
> > improve our communication of plans/directions/perceptions between the
> > teams so we don't adversely impact each other and see where we can
> > help each other moving forward.
>
> My biggest concern with Mogan is that it forks Nova, then starts
> changing interfaces. Nova's got 2 really big API surfaces.
>
> 1) The user facing API, which is reasonably well documented, and under
> tight control. Mogan has taken key things at 95% similarity and changed
> bits. So servers includes things like a partitions parameter.
> https://github.com/openstack/mogan/blob/master/api-ref/
> source/v1/servers.inc#request-4
>
> This being nearly the same but slightly different ends up being really
> weird. Especially as Nova evolves it's code with microversions for
> things like embedded flavor info.
>
>
For user facing API, We defined a new set of API instead of following Nova,
which is more specific for bare metals. The similarity of key things is
because virtual machines and bare metals key attributes are similar
naturally. Mogan is relatively new project, with more features introduced,
things will become different in future.


> 2) The guest facing API of metadata/config drive. This is far less
> documented or tested, and while we try to be strict about adding in
> information here in a versioned way, it's never seen the same attention
> as the user API on either documentation or version rigor.
>
> That's presumably getting changed, going to drift as well, which means
> discovering multiple implementations that are nearly, but not exactly
> the same that drift.
>
>
About guest facing API, we only support config drive now, which is copied
from Nova but we don't want to diverge from it. Regarding this part, we
will try to sync with nova periodically or maybe refactoring these files to
be a shared library is the best way, we will try to figure out.


>
> The point of licensing things under and Apache 2 license was to enable
> folks to do all kind of experiments like this. And experiments are good.
> But part of the point of experiments is to learn lessons to bring back
> into the fold. Digging out of the multi year hole of "close but not
> exactly the same" API differences between nova-net and neutron really
> makes me want to make sure we never intentionally inflict that confusion
> on folks again.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [Openstack-operators] [tc][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

Thanks Erik for the response!

I don't mean there are deficiencies in Ironic. Ironic itself is cool, it
works well with TripleO, Nova, Kolla, etc. Mogan just want to be another
client to schedule workloards on Ironic and provide bare metal specific
APIs for users who seeks a way to provider virtual machines and bare metals
separately, or just bare metal cloud without interoperble with other
compute resources under Nova.

On Wed, Sep 27, 2017 at 8:53 AM, Erik McCormick <emccorm...@cirrusseven.com>
wrote:

> My main question here would be this: If you feel there are deficiencies in
> Ironic, why not contribute to improving Ironic rather than spawning a whole
> new project?
>
> I am happy to take a look at it, and I'm by no means trying to contradict
> your assumptions here. I just get concerned with the overhead and confusion
> that comes with competing projects.
>
> Also, if you'd like to discuss this in detail with a room full of bodies,
> I suggest proposing a session for the Forum in Sydney. If some of the
> contributors will be there, it would be a good opportunity for you to get
> feedback.
>
> Cheers,
> Erik
>
>
> On Sep 26, 2017 8:41 PM, "Matt Riedemann" <mriede...@gmail.com> wrote:
>
>> On 9/25/2017 6:27 AM, Zhenguo Niu wrote:
>>
>>> Hi folks,
>>>
>>> First of all, thanks for the audiences for Mogan project update in the
>>> TC room during Denver PTG. Here we would like to get more suggestions
>>> before we apply for inclusion.
>>>
>>> Speaking only for myself, I find the current direction of one
>>> API+scheduler for vm/baremetal/container unfortunate. After containers
>>> management moved out to be a separated project Zun, baremetal with Nova and
>>> Ironic continues to be a pain point.
>>>
>>> #. API
>>> Only part of the Nova APIs and parameters can apply to baremetal
>>> instances, meanwhile for interoperable with other virtual drivers, bare
>>> metal specific APIs such as deploy time RAID, advanced partitions can not
>>>  be included. It's true that we can support various compute drivers, but
>>> the reality is that the support of each of hypervisor is not equal,
>>> especially for bare metals in a virtualization world. But I understand the
>>> problems with that as Nova was designed to provide compute
>>> resources(virtual machines) instead of bare metals.
>>>
>>> #. Scheduler
>>> Bare metal doesn't fit in to the model of 1:1 nova-compute to resource,
>>> as nova-compute processes can't be run on the inventory nodes themselves.
>>> That is to say host aggregates, availability zones and such things based on
>>> compute service(host) can't be applied to bare metal resources. And for
>>> grouping like anti-affinity, the granularity is also not same with virtual
>>> machines, bare metal users may want their HA instances not on the same
>>> failure domain instead of the node itself. Short saying, we can only get a
>>> rigid resource class only scheduling for bare metals.
>>>
>>>
>>> And most of the cloud providers in the market offering virtual machines
>>> and bare metals as separated resources, but unfortunately, it's hard to
>>> achieve this with one compute service. I heard people are deploying
>>> seperated Nova for virtual machines and bare metals with many downstream
>>> hacks to the bare metal single-driver Nova but as the changes to Nova would
>>> be massive and may invasive to virtual machines, it seems not practical to
>>> be upstream.
>>>
>>> So we created Mogan [1] about one year ago, which aims to offer bare
>>> metals as first class resources to users with a set of bare metal specific
>>> API and a baremetal-centric scheduler(with Placement service). It was like
>>> an experimental project at the beginning, but the outcome makes us believe
>>> it's the right way. Mogan will fully embrace Ironic for bare metal
>>> provisioning and with RSD server [2] introduced to OpenStack, it will be a
>>> new world for bare metals, as with that we can compose hardware resources
>>> on the fly.
>>>
>>> Also, I would like to clarify the overlaps between Mogan and Nova, I bet
>>> there must be some users who wants to use one API for the compute resources
>>> management as they don't care about whether it's a virtual machine or a
>>> bare metal server. Baremetal driver with Nova is still the right choice for
>>> such users to get raw performance compute resources. On the contrary, Mogan
>>> is for real bare m

Re: [openstack-dev] [infra][mogan] Need help for replacing the current master

[Zhenguo Niu]

Thanks Clark Boylan,

We have frozen the Mogan repo since this mail sent out, and there's no need
to update the replacement master. So please help out when you got time.

On Wed, Sep 27, 2017 at 8:10 AM, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Tue, Sep 26, 2017, at 02:18 AM, Zhenguo Niu wrote:
> > It's very appreciated if you shed some light on what the next steps would
> > be to move this along.
>
> We should schedule a period of time to freeze the Mogan repo, update the
> replacement master (if necessary) then we can either force push that
> over the existing branch or push it into a new branch and have you
> propose and then merge a merge commit. Considering that the purpose of
> this is to better update the history of the master branch the force push
> is likely the most appropriate option. Using a merge commit will result
> in potentially complicated history which won't help with the objective
> here.
>
> What is a good time to freeze, update and push? In total you probably
> want to allocate a day to this, we can likely get by with less but it is
> easy to block off a day and then we don't have to rush.
>
> Clark
>
> __
> 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
>



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

Re: [openstack-dev] [infra][mogan] Need help for replacing the current master

[Zhenguo Niu]

It's very appreciated if you shed some light on what the next steps would
be to move this along.

On Sat, Sep 23, 2017 at 10:03 AM, Sheng Liu <liusheng2...@gmail.com> wrote:

> Just confirmed the git history and compared the code with current Mogan
> master, it is OK!, Thanks a lot for dims to help that. we will very
> appreciate that Infra team can help us to replace the current Mogan master.
>
> --
> Best Regards
> liusheng
>
> 2017-09-22 21:53 GMT+08:00 Zhenguo Niu <niu.zgli...@gmail.com>:
>
>> Hi infra,
>>
>> In order to show respect to the original authors, we would like to
>> replace the current mogan master [1] with a new forked repo [2] which
>> includes the history of files which copied from other projects.
>>
>> The detailed discussion is here: http://lists.openstack.o
>> rg/pipermail/openstack-dev/2017-September/122470.html
>>
>> Thank you for your time!
>>
>> [1] https://github.com/openstack/mogan
>> [2] https://github.com/dims/mogan
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>> 
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

Thanks Dmitry for the feedback, please see my response inline.


On Mon, Sep 25, 2017 at 8:35 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> Hi!
>
> Thanks for raising this. I was interested in the project for some time,
> but I never got a chance to wrap my head around. I also have a few concerns
> - please see inline.
>
> On 09/25/2017 01:27 PM, Zhenguo Niu wrote:
>
>> Hi folks,
>>
>> First of all, thanks for the audiences for Mogan project update in the TC
>> room during Denver PTG. Here we would like to get more suggestions before
>> we apply for inclusion.
>>
>> Speaking only for myself, I find the current direction of one
>> API+scheduler for vm/baremetal/container unfortunate. After containers
>> management moved out to be a separated project Zun, baremetal with Nova and
>> Ironic continues to be a pain point.
>>
>> #. API
>> Only part of the Nova APIs and parameters can apply to baremetal
>> instances, meanwhile for interoperable with other virtual drivers, bare
>> metal specific APIs such as deploy time RAID, advanced partitions can not
>>  be included. It's true that we can support various compute drivers, but
>> the reality is that the support of each of hypervisor is not equal,
>> especially for bare metals in a virtualization world. But I understand the
>> problems with that as Nova was designed to provide compute
>> resources(virtual machines) instead of bare metals.
>>
>
> A correction: any compute resources.
>
> Nova works okay with bare metals. It's never going to work perfectly
> though, because we always have to find a common subset of features between
> VM and BM. RAID is a good example indeed. We have a solution for the
> future, but it's not going to satisfy everyone.
>
> Now I have a question: to which extend do you plan to maintain the "cloud"
> nature of the API? Let's take RAID as an example. Ironic can apply a very
> generic or a very specific configuration. You can request "just RAID-5" or
> you can ask for specific disks to be combined in a specific combination. I
> believe the latter is not something we want to expose to cloud users, as
> it's not going to be a cloud any more.
>
>
In fact, we don't have a clear spec for RAID support yet, but the team
tends to use a generic configuration just as the concerns you raised. But
if we can track disk information in Mogan or Placement(as a nested resource
provider with node), it's also possible for users to specify disks with
some hints like "SSD 500GB", then Mogan can match the disk and pass down a
specific configuration to Ironic. Anyhow, we should fully discuss this with
Ironic team after a spec proposed.

Besides RAID configuration, we already added partitions support when
claiming a server with parition images. But there is a limit to root,
ephemeral and swap as advanced partitions like LVM is not ready on Ironic
side. We are interested in working with Ironic team to make that done this
cycle.


>
>> #. Scheduler
>> Bare metal doesn't fit in to the model of 1:1 nova-compute to resource,
>> as nova-compute processes can't be run on the inventory nodes themselves.
>> That is to say host aggregates, availability zones and such things based on
>> compute service(host) can't be applied to bare metal resources. And for
>> grouping like anti-affinity, the granularity is also not same with virtual
>> machines, bare metal users may want their HA instances not on the same
>> failure domain instead of the node itself. Short saying, we can only get a
>> rigid resource class only scheduling for bare metals.
>>
>
> It's not rigid. Okay, it's rigid, but it's not as rigid as what we used to
> have.
>
> If you're going back to VCPUs-memory-disk triad, you're making it more
> rigid. Of these three, only memory has ever made practical sense for
> deployers. VCPUs is a bit subtle, as it depends on hyper-threading
> enabled/disabled, and I've never seen people using it too often.
>
> But our local_gb thing is an outright lie. Of 20 disks a machine can
> easily have, which one do you report for local_gb? Well, in the best case
> people used ironic root device hints with ironic-inspector to figure out.
> Which is great, but requires ironic-inspector. In the worst case people
> just put random number there to make scheduling work. This is horrible,
> please make sure to not get back to it.
>
>
I dont' mean to get back to the original VCPUs-memory-disk scheduling here.
Currently we just follow the "rigid" resource class scheduling as what nova
does but with node aggregates and affinity/anti-affinity grouping support.


> What I would love to see of a bare metal scheduling project is a
&

[openstack-dev] [tc][nova][ironic][mogan] Evaluate Mogan project

[Zhenguo Niu]

Hi folks,

First of all, thanks for the audiences for Mogan project update in the TC
room during Denver PTG. Here we would like to get more suggestions before
we apply for inclusion.

Speaking only for myself, I find the current direction of one API+scheduler
for vm/baremetal/container unfortunate. After containers management moved
out to be a separated project Zun, baremetal with Nova and Ironic continues
to be a pain point.

#. API
Only part of the Nova APIs and parameters can apply to baremetal instances,
meanwhile for interoperable with other virtual drivers, bare metal specific
APIs such as deploy time RAID, advanced partitions can not  be included.
It's true that we can support various compute drivers, but the reality is
that the support of each of hypervisor is not equal, especially for bare
metals in a virtualization world. But I understand the problems with that
as Nova was designed to provide compute resources(virtual machines) instead
of bare metals.

#. Scheduler
Bare metal doesn't fit in to the model of 1:1 nova-compute to resource, as
nova-compute processes can't be run on the inventory nodes themselves. That
is to say host aggregates, availability zones and such things based on
compute service(host) can't be applied to bare metal resources. And for
grouping like anti-affinity, the granularity is also not same with virtual
machines, bare metal users may want their HA instances not on the same
failure domain instead of the node itself. Short saying, we can only get a
rigid resource class only scheduling for bare metals.


And most of the cloud providers in the market offering virtual machines and
bare metals as separated resources, but unfortunately, it's hard to achieve
this with one compute service. I heard people are deploying seperated Nova
for virtual machines and bare metals with many downstream hacks to the bare
metal single-driver Nova but as the changes to Nova would be massive and
may invasive to virtual machines, it seems not practical to be upstream.

So we created Mogan [1] about one year ago, which aims to offer bare metals
as first class resources to users with a set of bare metal specific API and
a baremetal-centric scheduler(with Placement service). It was like an
experimental project at the beginning, but the outcome makes us believe
it's the right way. Mogan will fully embrace Ironic for bare metal
provisioning and with RSD server [2] introduced to OpenStack, it will be a
new world for bare metals, as with that we can compose hardware resources
on the fly.

Also, I would like to clarify the overlaps between Mogan and Nova, I bet
there must be some users who wants to use one API for the compute resources
management as they don't care about whether it's a virtual machine or a
bare metal server. Baremetal driver with Nova is still the right choice for
such users to get raw performance compute resources. On the contrary, Mogan
is for real bare metal users and cloud providers who wants to offer bare
metals as a separated resources.

Thank you for your time!


[1] https://wiki.openstack.org/wiki/Mogan
[2]
https://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-design-overview.html

-- 
Best Regards,
Zhenguo Niu
__
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][mogan] Need help for replacing the current master

[Zhenguo Niu]

Hi infra,

In order to show respect to the original authors, we would like to replace
the current mogan master [1] with a new forked repo [2] which includes the
history of files which copied from other projects.

The detailed discussion is here: http://lists.openstack.
org/pipermail/openstack-dev/2017-September/122470.html

Thank you for your time!

[1] https://github.com/openstack/mogan
[2] https://github.com/dims/mogan

-- 
Best Regards,
Zhenguo Niu
__
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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Thanks Sean for the suggestion, os-brick is indeed a good example for
sharing codes. Will discuss with the team to see if it's possible to move
that code into such a library.

On Fri, Sep 22, 2017 at 9:26 PM, Sean McGinnis <sean.mcgin...@gmx.com>
wrote:

> > >
> > > Luckily, since these things are part of the ABI of Nova, they are
> > > versioned in many cases, and in all have a well defined interfaces on
> > > one side. Seems like it should be relatively straight forward to wrap
> > > the other side of them and call it a library.
> > >
> > > 
> __
> > > 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
> > >
> >
> > Sounds great if we can call these ABI as a library, but seems still need
> > some refactoring on Nova side to make other projects be able to leverage
> it.
> >
>
> I wouldn't drop the idea because of that. In the case of the os-brick
> library, there was common code for interacting with local storage
> management in both Cinder and Nova. We recognized this and started the
> os-brick library to move that code into one place.
>
> Cinder started using it right away, but it was at least a couple cycles
> before Nova started looking at it. I think that's perfectly fine. If
> you are able to start a library for your own use, and it has good and
> useful common functionality, then Nova can make the decision later if
> they want to take advantage of it.
>
> Sean
>
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

@Dims, sure, will make a formal request, thanks!

On Fri, Sep 22, 2017 at 8:45 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> @Zhenguo,
>
> Can you make a formal request via email? add "[infra]" and "[mogan]"
> tags so everyone in mogan is aware of this and the infra folks give
> their ok. Then we can ping infra using "infra-root" on the
> #openstack-infra channel and ask them to replace.
>
> Sounds good?
>
> Thanks,
> Dims
>
> On Fri, Sep 22, 2017 at 8:41 AM, Zhenguo Niu <niu.zgli...@gmail.com>
> wrote:
> > @Dims,
> >
> > Yes, I think the history is OK, do I need to ping some infra guys or if
> you
> > can help to replace the repo?
> >
> > On Fri, Sep 22, 2017 at 7:22 PM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>
> >> @Zhenguo,
> >>
> >> Can you please confirm that the history looks good?
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu <niu.zgli...@gmail.com>
> >> wrote:
> >> > Thanks dims, that's cool :D
> >> >
> >> > I'll make sure there's no new patches landed to master before
> replacing
> >> > the
> >> > repo.
> >> >
> >> > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas <dava...@gmail.com>
> >> > wrote:
> >> >>
> >> >> Zhenguo,
> >> >>
> >> >> I did some fancy surgery with both cinder and nova repos to add the
> >> >> history, please check my repo here:
> >> >> https://github.com/dims/mogan/commits/master
> >> >>
> >> >> (Needed quota.py from cinder and rest of the files from Nova)
> >> >>
> >> >> If that repo looks good, then we can request infra folks to replace
> >> >> the current master with that one.
> >> >>
> >> >> Thanks,
> >> >> Dims
> >> >>
> >> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <
> mriede...@gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
> >> >> >>>
> >> >> >>> On 15:56 Sep 20, Flavio Percoco wrote:
> >> >> >>>>
> >> >> >>>> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> >> >> >>>>>
> >> >> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> >> >> >>>>> [...]
> >> >> >>>>>>
> >> >> >>>>>> please indicate which file from Nova, so if anyone wanted to
> >> >> >>>>>> cross
> >> >> >>>>>> check for fixes etc can go look in Nova
> >> >> >>>>>
> >> >> >>>>> [...]
> >> >> >>>>>
> >> >> >>>>> While the opportunity has probably passed in this case, the
> ideal
> >> >> >>>>> method is to start with a Git fork of the original as your seed
> >> >> >>>>> project (perhaps with history pruned to just the files you're
> >> >> >>>>> reusing via git filter-branch or similar). This way the
> complete
> >> >> >>>>> change history of the files in question is preserved for future
> >> >> >>>>> inspection.
> >> >> >>>>
> >> >> >>>>
> >> >> >>>> If it's not too late, I would definitely recommend going with a
> >> >> >>>> fork,
> >> >> >>>> fwiw.
> >> >> >>>>
> >> >> >>>> Flavio
> >> >> >>>>
> >> >> >>>> --
> >> >> >>>> @flaper87
> >> >> >>>> Flavio Percoco
> >> >> >>>
> >> >> >>>
> >> >> >>> +1 please fork instead.
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >> >> >>>
> >>

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

@Dims,

Yes, I think the history is OK, do I need to ping some infra guys or if you
can help to replace the repo?

On Fri, Sep 22, 2017 at 7:22 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> @Zhenguo,
>
> Can you please confirm that the history looks good?
>
> Thanks,
> Dims
>
> On Fri, Sep 22, 2017 at 1:35 AM, Zhenguo Niu <niu.zgli...@gmail.com>
> wrote:
> > Thanks dims, that's cool :D
> >
> > I'll make sure there's no new patches landed to master before replacing
> the
> > repo.
> >
> > On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >>
> >> Zhenguo,
> >>
> >> I did some fancy surgery with both cinder and nova repos to add the
> >> history, please check my repo here:
> >> https://github.com/dims/mogan/commits/master
> >>
> >> (Needed quota.py from cinder and rest of the files from Nova)
> >>
> >> If that repo looks good, then we can request infra folks to replace
> >> the current master with that one.
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com>
> >> wrote:
> >> >
> >> >
> >> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com>
> >> > wrote:
> >> >>
> >> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
> >> >>>
> >> >>> On 15:56 Sep 20, Flavio Percoco wrote:
> >> >>>>
> >> >>>> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> >> >>>>>
> >> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> >> >>>>> [...]
> >> >>>>>>
> >> >>>>>> please indicate which file from Nova, so if anyone wanted to
> cross
> >> >>>>>> check for fixes etc can go look in Nova
> >> >>>>>
> >> >>>>> [...]
> >> >>>>>
> >> >>>>> While the opportunity has probably passed in this case, the ideal
> >> >>>>> method is to start with a Git fork of the original as your seed
> >> >>>>> project (perhaps with history pruned to just the files you're
> >> >>>>> reusing via git filter-branch or similar). This way the complete
> >> >>>>> change history of the files in question is preserved for future
> >> >>>>> inspection.
> >> >>>>
> >> >>>>
> >> >>>> If it's not too late, I would definitely recommend going with a
> fork,
> >> >>>> fwiw.
> >> >>>>
> >> >>>> Flavio
> >> >>>>
> >> >>>> --
> >> >>>> @flaper87
> >> >>>> Flavio Percoco
> >> >>>
> >> >>>
> >> >>> +1 please fork instead.
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> 
> __
> >> >>> 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
> >> >>>
> >> >>
> >> >> I'm pretty sure this ship has sailed. Mogan has been around since
> >> >> before
> >> >> the PTG in Atlanta.
> >> >>
> >> >> --
> >> >>
> >> >> Thanks,
> >> >>
> >> >> Matt
> >> >>
> >> >>
> >> >>
> >> >> 
> __
> >> >> OpenStack Development Mailing List (not for usage questions)
> >> >> Unsubscribe:
> >> >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> > Yes, we are way past that, and there are already 1000+ commits since
> >> > Mogan
> >> > created,
> >> >
> >> > --
> >> > Best Regard

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Thanks dims, that's cool :D

I'll make sure there's no new patches landed to master before replacing the
repo.

On Fri, Sep 22, 2017 at 9:53 AM, Davanum Srinivas <dava...@gmail.com> wrote:

> Zhenguo,
>
> I did some fancy surgery with both cinder and nova repos to add the
> history, please check my repo here:
> https://github.com/dims/mogan/commits/master
>
> (Needed quota.py from cinder and rest of the files from Nova)
>
> If that repo looks good, then we can request infra folks to replace
> the current master with that one.
>
> Thanks,
> Dims
>
> On Thu, Sep 21, 2017 at 9:21 PM, Zhenguo Niu <niu.zgli...@gmail.com>
> wrote:
> >
> >
> > On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com>
> wrote:
> >>
> >> On 9/21/2017 11:55 AM, Mike Perez wrote:
> >>>
> >>> On 15:56 Sep 20, Flavio Percoco wrote:
> >>>>
> >>>> On 20/09/17 12:21 +, Jeremy Stanley wrote:
> >>>>>
> >>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
> >>>>> [...]
> >>>>>>
> >>>>>> please indicate which file from Nova, so if anyone wanted to cross
> >>>>>> check for fixes etc can go look in Nova
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>> While the opportunity has probably passed in this case, the ideal
> >>>>> method is to start with a Git fork of the original as your seed
> >>>>> project (perhaps with history pruned to just the files you're
> >>>>> reusing via git filter-branch or similar). This way the complete
> >>>>> change history of the files in question is preserved for future
> >>>>> inspection.
> >>>>
> >>>>
> >>>> If it's not too late, I would definitely recommend going with a fork,
> >>>> fwiw.
> >>>>
> >>>> Flavio
> >>>>
> >>>> --
> >>>> @flaper87
> >>>> Flavio Percoco
> >>>
> >>>
> >>> +1 please fork instead.
> >>>
> >>>
> >>>
> >>>
> >>> 
> __
> >>> 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
> >>>
> >>
> >> I'm pretty sure this ship has sailed. Mogan has been around since before
> >> the PTG in Atlanta.
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Matt
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > Yes, we are way past that, and there are already 1000+ commits since
> Mogan
> > created,
> >
> > --
> > Best Regards,
> > Zhenguo Niu
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Thu, Sep 21, 2017 at 1:33 PM, Clint Byrum <cl...@fewbar.com> wrote:

> Excerpts from Michael Still's message of 2017-09-20 10:25:17 -0600:
> > Dims, I'm not sure that's actually possible though. Many of these files
> > have been through rewrites and developed over a large number of years.
> > Listing all authors isn't practical.
> >
> > Given the horse has bolted on forking these files, I feel like a comment
> > acknowledging the original source file is probably sufficient.
> >
> > What is concerning to me is that some of these files are part of the
> "ABI"
> > of nova, and if mogan diverges from that then I think we're going to see
> > user complaints in the future. Specifically configdrive, and metadata
> seem
> > like examples of this. I don't want to see us end up in another "managed
> > cut and paste" like early oslo where nova continues to develop these and
> > mogan doesn't notice the changes.
> >
> > I'm not sure how we resolve that. One option would be to refactor these
> > files into a shared library.
> >
>
> Agreed 100%. It would be better to have something completely different
> than something that works 97% the same but constantly skews.
>
> Luckily, since these things are part of the ABI of Nova, they are
> versioned in many cases, and in all have a well defined interfaces on
> one side. Seems like it should be relatively straight forward to wrap
> the other side of them and call it a library.
>
> __
> 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
>

Sounds great if we can call these ABI as a library, but seems still need
some refactoring on Nova side to make other projects be able to leverage it.

-- 
Best Regards,
Zhenguo Niu
__
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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Wed, Sep 20, 2017 at 7:51 PM, Davanum Srinivas <dava...@gmail.com> wrote:

> Zhenguo,
>
> Thanks for bringing this up.
>
> For #1, yes please indicate which file from Nova, so if anyone wanted
> to cross check for fixes etc can go look in Nova
> For #2, When you pick up a commit from Nova, please make sure the
> commit message in Mogan has the following
>* The gerrit change id(s) of the original commit, so folks can
> easily go find the original commit in gerritt
>* Add "Co-Authored-By:" tags for each author in the original commit
> so they get credit
>
> Also, Please make sure you do not alter any copyright or license
> related information in the header when you first copy a file from
> another project.
>

Sure, we will keep the original copyright and license in the header.


>
> Thanks,
> Dims
>
> On Wed, Sep 20, 2017 at 4:20 AM, Zhenguo Niu <niu.zgli...@gmail.com>
> wrote:
> > Hi all,
> >
> > I'm from Mogan team, we copied some codes/frameworks from Nova since we
> want
> > to be a Nova with a bare metal specific API.
> > About why reinventing the wheel, you can find more informations here [1].
> >
> > I would like to know what's the decent way to show our respect to the
> > original authors we copied from.
> >
> > After discussing with the team, we plan to do some improvements as below:
> >
> > 1. Adds some comments to the beginning of such files to indicate that
> they
> > leveraged the implementation of Nova.
> >
> > https://github.com/openstack/mogan/blob/master/mogan/
> baremetal/ironic/driver.py#L19
> > https://github.com/openstack/mogan/blob/master/mogan/
> console/websocketproxy.py#L17-L18
> > https://github.com/openstack/mogan/blob/master/mogan/
> consoleauth/manager.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> engine/configdrive.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> engine/metadata.py#L18
> > https://github.com/openstack/mogan/blob/master/mogan/network/api.py#L18
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/aggregate.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/keypair.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/server_fault.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> objects/server_group.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> scheduler/client/report.py#L17
> > https://github.com/openstack/mogan/blob/master/mogan/
> scheduler/filter_scheduler.py#L17
> >
> > 2. For the changes we follows what nova changed, should reference to the
> > original authors in the commit messages.
> >
> >
> > Please let me know if there are something else we need to do or there are
> > already some existing principles we can follow, thanks!
> >
> >
> >
> > [1] https://wiki.openstack.org/wiki/Mogan
> >
> >
> > --
> > Best Regards,
> > Zhenguo Niu
> >
> > 
> __
> > 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
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Thanks John Dickinson, we can follow Swift's way but as Michael Still
mentioned seems listing all authors isn't practical.

On Thu, Sep 21, 2017 at 5:43 AM, John Dickinson <m...@not.mn> wrote:

>
>
> On 20 Sep 2017, at 9:25, Michael Still wrote:
>
> > Dims, I'm not sure that's actually possible though. Many of these files
> > have been through rewrites and developed over a large number of years.
> > Listing all authors isn't practical.
> >
> > Given the horse has bolted on forking these files, I feel like a comment
> > acknowledging the original source file is probably sufficient.
>
> In Swift's repo, we acknowledge the original authors in a section of the
> AUTHORS file
>
> https://github.com/openstack/swift/blob/master/AUTHORS
>
> --John
>
>
>
> >
> > What is concerning to me is that some of these files are part of the
> "ABI"
> > of nova, and if mogan diverges from that then I think we're going to see
> > user complaints in the future. Specifically configdrive, and metadata
> seem
> > like examples of this. I don't want to see us end up in another "managed
> > cut and paste" like early oslo where nova continues to develop these and
> > mogan doesn't notice the changes.
> >
> > I'm not sure how we resolve that. One option would be to refactor these
> > files into a shared library.
> >
> > Michael
> >
> >
> >
> >
> > On Wed, Sep 20, 2017 at 5:51 AM, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >
> >> Zhenguo,
> >>
> >> Thanks for bringing this up.
> >>
> >> For #1, yes please indicate which file from Nova, so if anyone wanted
> >> to cross check for fixes etc can go look in Nova
> >> For #2, When you pick up a commit from Nova, please make sure the
> >> commit message in Mogan has the following
> >>* The gerrit change id(s) of the original commit, so folks can
> >> easily go find the original commit in gerritt
> >>* Add "Co-Authored-By:" tags for each author in the original commit
> >> so they get credit
> >>
> >> Also, Please make sure you do not alter any copyright or license
> >> related information in the header when you first copy a file from
> >> another project.
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Wed, Sep 20, 2017 at 4:20 AM, Zhenguo Niu <niu.zgli...@gmail.com>
> >> wrote:
> >>> Hi all,
> >>>
> >>> I'm from Mogan team, we copied some codes/frameworks from Nova since we
> >> want
> >>> to be a Nova with a bare metal specific API.
> >>> About why reinventing the wheel, you can find more informations here
> [1].
> >>>
> >>> I would like to know what's the decent way to show our respect to the
> >>> original authors we copied from.
> >>>
> >>> After discussing with the team, we plan to do some improvements as
> below:
> >>>
> >>> 1. Adds some comments to the beginning of such files to indicate that
> >> they
> >>> leveraged the implementation of Nova.
> >>>
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> baremetal/ironic/driver.py#L19
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> console/websocketproxy.py#L17-L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> consoleauth/manager.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> engine/configdrive.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> engine/metadata.py#L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> network/api.py#L18
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/aggregate.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/keypair.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/server_fault.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> objects/server_group.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> scheduler/client/report.py#L17
> >>> https://github.com/openstack/mogan/blob/master/mogan/
> >> scheduler/filter_scheduler.py#L17
> >>>
> >>> 2. For the changes we follows what nova changed, should reference to
> the
> >>> original authors in the commit messages.
> &g

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

On Fri, Sep 22, 2017 at 5:48 AM, Matt Riedemann <mriede...@gmail.com> wrote:

> On 9/21/2017 11:55 AM, Mike Perez wrote:
>
>> On 15:56 Sep 20, Flavio Percoco wrote:
>>
>>> On 20/09/17 12:21 +, Jeremy Stanley wrote:
>>>
>>>> On 2017-09-20 07:51:29 -0400 (-0400), Davanum Srinivas wrote:
>>>> [...]
>>>>
>>>>> please indicate which file from Nova, so if anyone wanted to cross
>>>>> check for fixes etc can go look in Nova
>>>>>
>>>> [...]
>>>>
>>>> While the opportunity has probably passed in this case, the ideal
>>>> method is to start with a Git fork of the original as your seed
>>>> project (perhaps with history pruned to just the files you're
>>>> reusing via git filter-branch or similar). This way the complete
>>>> change history of the files in question is preserved for future
>>>> inspection.
>>>>
>>>
>>> If it's not too late, I would definitely recommend going with a fork,
>>> fwiw.
>>>
>>> Flavio
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>
>> +1 please fork instead.
>>
>>
>>
>> 
>> __
>> 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
>>
>>
> I'm pretty sure this ship has sailed. Mogan has been around since before
> the PTG in Atlanta.
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Yes, we are way past that, and there are already 1000+ commits since Mogan
created,

-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Weekly meeting canceled this week

[Zhenguo Niu]

Hello team,

I'll cancel tomorrow's IRC meeting due to the virtual PTG this Friday.

See you all on next meeting!

-- 
Best Regards,
Zhenguo Niu
__
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] [tc][nova][mogan] How to show respect to the original authors?

[Zhenguo Niu]

Hi all,

I'm from Mogan team, we copied some codes/frameworks from Nova since we
want to be a Nova with a bare metal specific API.
About why reinventing the wheel, you can find more informations here [1].

I would like to know what's the decent way to show our respect to the
original authors we copied from.

After discussing with the team, we plan to do some improvements as below:

1. Adds some comments to the beginning of such files to indicate that they
leveraged the implementation of Nova.

https://github.com/openstack/mogan/blob/master/mogan/baremetal/ironic/driver.py#L19
https://github.com/openstack/mogan/blob/master/mogan/console/websocketproxy.py#L17-L18
https://github.com/openstack/mogan/blob/master/mogan/consoleauth/manager.py#L17
https://github.com/openstack/mogan/blob/master/mogan/engine/configdrive.py#L17
https://github.com/openstack/mogan/blob/master/mogan/engine/metadata.py#L18
https://github.com/openstack/mogan/blob/master/mogan/network/api.py#L18
https://github.com/openstack/mogan/blob/master/mogan/objects/aggregate.py#L17
https://github.com/openstack/mogan/blob/master/mogan/objects/keypair.py#L17
https://github.com/openstack/mogan/blob/master/mogan/objects/server_fault.py#L17
https://github.com/openstack/mogan/blob/master/mogan/objects/server_group.py#L17
https://github.com/openstack/mogan/blob/master/mogan/scheduler/client/report.py#L17
https://github.com/openstack/mogan/blob/master/mogan/scheduler/filter_scheduler.py#L17

2. For the changes we follows what nova changed, should reference to the
original authors in the commit messages.


Please let me know if there are something else we need to do or there are
already some existing principles we can follow, thanks!



[1] https://wiki.openstack.org/wiki/Mogan


-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] 0.1.0 release

[Zhenguo Niu]

Hi folks,

Today Mogan has been released first time, thanks all great people and
contributors who worked on Mogan 0.1.0 and everybody who helped us!

Mogan is a project which offers bare metals as first class resources to
users. During 0.1.0, we have almost wrapped up the work to catch up with
nova and filled the gaps between bare metals and virtual machines such as
aggregates and server groups.

Here are our release notes:
http://mogan.readthedocs.io/projects/releasenotes/en/latest/0.1.0.html

Other useful links:

- Wiki: https://wiki.openstack.org/wiki/Mogan
- Documentation: http://mogan.readthedocs.io/en/latest/
- APIs: http://mogan.readthedocs.io/projects/api-ref/en/latest/
- Source: https://git.openstack.org/cgit/openstack/mogan
- Launchpad: https://launchpad.net/mogan


-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] python-moganclient 0.1.0 released

[Zhenguo Niu]

hi all,

python-moganclient 0.1.0 released.

Tarball: http://tarballs.openstack.org/python-moganclient/
PYPI: https://pypi.python.org/pypi/python-moganclient/

-- 
Best Regards,
Zhenguo Niu
__
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] [Mogan] Queens PTL candidacy

[Zhenguo Niu]

Hi all,

I would like to announce my candidacy for the Mogan PTL for the Queens
cycle. Although Mogan is not an official project yet, we seek to complete
the PTL election with everyone’s consensus like others.



I have been the elected PTL since Mogan was an idea. I think that Mogan
serves an important role in current OpenStack ecosystem and solve problems
that many users are facing. Mogan is relatively new project but I am proud
to say that we already have a diverse community and feel that we operate
openly and advancing in the right direction.



If I’m getting an opportunity to continue serving the team for the Queens
cycle, I’d strive to work with the team on the following items:



- Support RAID at deploy time

- Boot from volume and Migrate/Resize support for such diskless servers

- Change to use nested resources model for bare metals in placement to
track NICs and DISKs as well.

- Improve bare metal node aggregates support by leveraging Placement service

- Add more policies for bare metal server groups

- Valence integration to support composing hardware



We will follow the official procedure. Any self nominations need be in
within a week from now. If there are more than one candidate we will create
a poll on http://civs.cs.cornell.edu/ .


-- 
Best Regards,
Zhenguo Niu
__
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] [ironic][nova] Goodbye^W See you later

[Zhenguo Niu]

Thanks for everything jroll and best wishes on your new endeavors!

On Thu, Jun 8, 2017 at 8:45 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> Hey friends,
>
> I've been mostly missing for the past six weeks while looking for a new
> job, so maybe you've forgotten me already, maybe not. I'm happy to tell you
> I've found one that I think is a great opportunity for me. But, I'm sad to
> tell you that it's totally outside of the OpenStack community.
>
> The last 3.5 years have been amazing. I'm extremely grateful that I've
> been able to work in this community - I've learned so much and met so many
> awesome people. I'm going to miss the insane(ly awesome) level of
> collaboration, the summits, the PTGs, and even some of the bikeshedding.
> We've built amazing things together, and I'm sure y'all will continue to do
> so without me.
>
> I'll still be lurking in #openstack-dev and #openstack-ironic for a while,
> if people need me to drop a -2 or dictate old knowledge or whatever, feel
> free to ping me. Or if you just want to chat. :)
>
> <3 jroll
>
> P.S. obviously my core permissions should be dropped now :P
>
> __
> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 10:01 PM, Jay Pipes <jaypi...@gmail.com> wrote:

> On 05/31/2017 01:31 AM, Zhenguo Niu wrote:
>
>> On Wed, May 31, 2017 at 12:20 PM, Ed Leafe <e...@leafe.com > e...@leafe.com>> wrote:
>>
>>     On May 30, 2017, at 9:36 PM, Zhenguo Niu <niu.zgli...@gmail.com
>> <mailto:niu.zgli...@gmail.com>> wrote:
>>
>> > as placement is not splitted out from nova now, and there would be
>> users who only want a baremetal cloud, so we don't add resources to
>> placement yet, but it's easy for us to turn to placement to match the node
>> type with mogan flavors.
>>
>> Placement is a separate service, independent of Nova. It tracks
>> Ironic nodes as individual resources, not as a "pretend" VM. The
>> Nova integration for selecting an Ironic node as a resource is still
>> being developed, as we need to update our view of the mess that is
>> "flavors", but the goal is to have a single flavor for each Ironic
>> machine type, rather than the current state of flavors pretending
>> that an Ironic node is a VM with certain RAM/CPU/disk quantities.
>>
>>
>> Yes, I understand the current efforts of improving the baremetal nodes
>> scheduling. It's not conflict with mogan's goal, and when it is done, we
>> can share the same scheduling strategy with placement :)
>>
>> Mogan is a service for a specific group of users who really want a
>> baremetal resource instead of a generic compute resource, on API side, we
>> can expose RAID, advanced partitions, nics bonding, firmware management,
>> and other baremetal specific capabilities to users. And unlike nova's host
>> based availability zone, host aggregates, server groups (ironic nodes share
>> the same host), mogan can make it possible to divide baremetal nodes into
>> such groups, and make Rack aware for affinity and anti-affinity when
>> scheduling.
>>
> Zhenguo Niu brings up a very good point here. Currently, all Ironic nodes
> are associated with a single host aggregate in Nova, because of the
> vestigial notion that a compute *service* (ala the nova-compute worker) was
> equal to the compute *node*.
>
> In the placement API, of course, there's no such coupling. A placement
> aggregate != a Nova host aggregate.
>
> So, technically Ironic (or Mogan) can call the placement service to create
> aggregates that match *its* definition of what an aggregate is (rack, row,
> cage, zone, DC, whatever). Furthermore, Ironic (or Mogan) can associate
> Ironic baremetal nodes to one or more of those placement aggregates to get
> around Nova host aggregate to compute service coupling.
>
> That said, there's still lots of missing pieces before placement gets
> affinity/anti-affinity support...
>

Thanks Jay, we are also considering how to leverage the placement
aggregates, and if possible, we would like to contribute in this part to
make placement work well for mogan :)


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



-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Architecture diagrams

[Zhenguo Niu]

On Thu, Jun 1, 2017 at 4:06 AM, Joshua Harlow <harlo...@fastmail.com> wrote:

> Hi mogan folks,
>
> I was doing some source code examination of mogan and it peaked my
> interest in how it all is connected together. In part I see there is a
> state machine, some taskflow usage, some wsgi usage that looks like parts
> of it are inspired(?) by various other projects.
>
> That got me wondering if there is any decent diagrams or documents that
> explain how it all connects together and I thought I might as well ask and
> see if there are any (50/50 chances? ha).
>

hi Josh, you can find some diagrams/documents on our wiki [1], sorry for
the lack of docs, will enrich it soon.


>
> I am especially interested in the state machine, taskflow and such (no
> tooz seems to be there) and how they are used (if they are, or are going to
> be used); I guess in part because I know the most about those
> libraries/components :)
>
>
In fact, we use the same state machine library like ironic to help control
the baremetal server state change. And we introduced a linear taskflow for
create_server to reliably ensure that workflow is executed in a manner that
can survie process failure by reverting. It's great if we can get
help/suggestions from a taskflow expert :)


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


[1] https://wiki.openstack.org/wiki/Mogan

-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 12:20 PM, Ed Leafe <e...@leafe.com> wrote:

> On May 30, 2017, at 9:36 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote:
>
> > as placement is not splitted out from nova now, and there would be users
> who only want a baremetal cloud, so we don't add resources to placement
> yet, but it's easy for us to turn to placement to match the node type with
> mogan flavors.
>
> Placement is a separate service, independent of Nova. It tracks Ironic
> nodes as individual resources, not as a "pretend" VM. The Nova integration
> for selecting an Ironic node as a resource is still being developed, as we
> need to update our view of the mess that is "flavors", but the goal is to
> have a single flavor for each Ironic machine type, rather than the current
> state of flavors pretending that an Ironic node is a VM with certain
> RAM/CPU/disk quantities.
>

Yes, I understand the current efforts of improving the baremetal nodes
scheduling. It's not conflict with mogan's goal, and when it is done, we
can share the same scheduling strategy with placement :)

Mogan is a service for a specific group of users who really want a
baremetal resource instead of a generic compute resource, on API side, we
can expose RAID, advanced partitions, nics bonding, firmware management,
and other baremetal specific capabilities to users. And unlike nova's host
based availability zone, host aggregates, server groups (ironic nodes share
the same host), mogan can make it possible to divide baremetal nodes into
such groups, and make Rack aware for affinity and anti-affinity when
scheduling.


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


-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

On Wed, May 31, 2017 at 10:20 AM, Ed Leafe <e...@leafe.com> wrote:

> On May 30, 2017, at 9:08 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote:
>
> > There would be a collision if nova and mogan consume the same ironic
> nodes cluster, as both of them will see all the available node resources.
> So if someone wants to choose mogan for baremetal compute management, the
> recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for
> VMs, this way we treat baremetals and vms as different compute resources.
> In a cloud with both vms and baremetals, it's more clear to have different
> set of APIs to manage them if users really care about what resources they
> got instead of just the performance. We also create a mogan horizon plugin
> which adds separated baremetal servers panel[1].
>
> So Mogan does not use the placement service for tracking resources?
>

as placement is not splitted out from nova now, and there would be users
who only want a baremetal cloud, so we don't add resources to placement
yet, but it's easy for us to turn to placement to match the node type with
mogan flavors.


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


-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan][nova] mogan and nova co-existing

[Zhenguo Niu]

Thanks Ruby for bringing this up!

There would be a collision if nova and mogan consume the same ironic nodes
cluster, as both of them will see all the available node resources. So if
someone wants to choose mogan for baremetal compute management, the
recommended deployment is Mogan+Ironic for baremetals and Nova+Libvirt for
VMs, this way we treat baremetals and vms as different compute resources.
In a cloud with both vms and baremetals, it's more clear to have different
set of APIs to manage them if users really care about what resources they
got instead of just the performance. We also create a mogan horizon plugin
which adds separated baremetal servers panel[1].

But for users who don't care whether it's a vm or baremetal server, they
just want to ask OpenStack for a specific flavor of compute resource to run
the workloads, it's definitely no need to deploy Mogan to separate
baremetals to a different compute resource to expose full baremetal
capabilities.


[1] https://pasteboard.co/cJ889Y7IA.png


On Mon, May 29, 2017 at 9:55 PM, Loo, Ruby <ruby@intel.com> wrote:

> Hi Zhenguo (and others),
>
>
>
> is there a description/email thread/documentation about how mogan and nova
> co-exists in the same cloud? In particular, will it be possible for mogan
> and nova (with ironic driver) to run? Is this something that we will
> recommend or not recommend or not mention? Because I don't see how the end
> user will know to issue a mogan command to get a baremetal server, vs a
> nova-boot command to get a baremetal server. And/or does anyone envison
> that horizon will hide all that from the user somehow?
>
>
>
> --ruby
>
>
>
> *From: *Zhenguo Niu <niu.zgli...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, May 25, 2017 at 10:41 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same
> keyword 'baremetal'?
>
>
>
> 
>
>
>
> As I understand, baremetal instance in nova is a 'specical virtual
> machine'(raw performance). Users claim the instance by specifying a flavor
> with 'vcpus', 'memory', "root_gb" instead of real hardware specs like (cpu
> model/cores, hard drives type/amount, nics type/amount), then he get an
> instance with properties like 'vm_state' and other 'virtual' stuff. As
> baremetal in nova use the same model and same set of API that designed for
> vms, so even for end users, it's not that easy to know which instance is a
> baremetal server, so maybe it's good to call that baremetal server a
> special vm instance.
>
>
>
> So, yes the end user actually know that there is a difference between
> getting a bremetal instance via mogan or via nova :)
>
> __
> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 9:37 PM, Loo, Ruby <ruby@intel.com> wrote:

> Hi Zhenguo,
>
>
>
> Thanks for bringing this up. Naming is hard :-(
>
>
>
> Maybe this is a dumb question but your phrase "We copied nova's server
> resource concept here, so users may easily to accept the 'baremetal
> server'" made me wonder. I'm not a user of Mogan so I don't know if this
> would work, but OSC already has
>
> openstack server  
>
> openstack flavor  
>
> openstack keypair  
>
>
>
> Why can't we use the existing OSC commands, and add an option eg '--bm' to
> indicate that the server is baremetal, not a VM?
>
>
>

Not sure if it's possible to achieve this by two different OSC plugins, and
as we use different options/parameters with nova when creating a baremetal
server, so I think it's hard to control by only a '--bm' option to
distinguish.
And compared with vm servers, baremetal servers have different
capabilities, it will make more confusing if you use 'openstack server
create' to create a baremetal instance, but you can't apply below commands
to it.

openstack server --bm pause/unpause
openstack server --bm shelve/unshelve
openstack server --bm migrate


> Of course, having asked this, how does the user know/distinguish between
> getting a baremetal instance via mogan or via nova... (and should the end
> user actually know that there is a difference...) But I suspect I am
> digressing.
>
>
>
As I understand, baremetal instance in nova is a 'specical virtual
machine'(raw performance). Users claim the instance by specifying a flavor
with 'vcpus', 'memory', "root_gb" instead of real hardware specs like (cpu
model/cores, hard drives type/amount, nics type/amount), then he get an
instance with properties like 'vm_state' and other 'virtual' stuff. As
baremetal in nova use the same model and same set of API that designed for
vms, so even for end users, it's not that easy to know which instance is a
baremetal server, so maybe it's good to call that baremetal server a
special vm instance.

So, yes the end user actually know that there is a difference between
getting a bremetal instance via mogan or via nova :)


> --ruby
>
>
>
> *From: *Zhenguo Niu <niu.zgli...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, May 25, 2017 at 5:38 AM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same
> keyword 'baremetal'?
>
>
>
>
>
> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtant...@redhat.com>
> wrote:
>
> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>
> hi all,
>
>
> Hi!
>
>
> I'm from the Mogan team, we chose the same keyward 'baremetal' when
> implementing a OSC plugin [1]. As we think the baremetal command is
> representative of a baremetal resource, not a service, so it makes sense
> for different projects to share the top level resource name that OpenStack
> can provide.
>
>
> We do not "own" the word "baremetal", so nothing prevents you from using
> it. However, in my experience:
> 1. This does confuse users, as they expect "openstack baremetal" to be a
> prefix belonging to Ironic.
> 2. Collisions may happen. We had two collisions with TripleO already, one
> resulted in us killing a TripleO command abruptly.
>
>
>
> Alternatively, I don't mind to change this to 'bm' or something like that
> for Mogan, but some operators told me that it will confuse users more to
> have both 'baremetal' and 'bm' in there CLI.
>
> And as I understand, ironic commands are not used frequently, and it's
> even less if ironic inspector can help to automatically enroll nodes/ports.
>
>
>
>
>
>
> The commands we have implemented are listed below, seems there's no
> collision with Ironic presently, and Ironic doesn't manage such resources.
>
> * openstack baremetal server  
> * openstack bareemtal flavor  
> * openstack baremetal keypair  
> * openstack baremetal availability zone  
>
>
> Ironic does not have any notion of either of these, so it should be fine.
>
> I'm still a bit on a -1 side because of potential users confusion. I
> wonder how can we send a message across that prefixes do not designate a
> specific project, but are rather just part of a "sentence". I'm
> specifically worried about confusing "baremetal server" of Mogan with
> "baremetal node" of Ironic. For many people these can be synonyms.
>
>
>
> We copied nova's 

Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 9:29 PM, Mark Goddard <m...@stackhpc.com> wrote:

> On 25 May 2017 at 11:03, Dmitry Tantsur <dtant...@redhat.com> wrote:
>
>> On 05/25/2017 11:38 AM, Zhenguo Niu wrote:
>>
>>>
>>> On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtant...@redhat.com
>>> <mailto:dtant...@redhat.com>> wrote:
>>>
>>> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>>>
>>> hi all,
>>>
>>>
>>> Hi!
>>>
>>>
>>> I'm from the Mogan team, we chose the same keyward 'baremetal'
>>> when
>>> implementing a OSC plugin [1]. As we think the baremetal command
>>> is
>>> representative of a baremetal resource, not a service, so it
>>> makes sense
>>> for different projects to share the top level resource name that
>>> OpenStack can provide.
>>>
>>>
>>> We do not "own" the word "baremetal", so nothing prevents you from
>>> using it.
>>> However, in my experience:
>>> 1. This does confuse users, as they expect "openstack baremetal" to
>>> be a
>>> prefix belonging to Ironic.
>>> 2. Collisions may happen. We had two collisions with TripleO
>>> already, one
>>> resulted in us killing a TripleO command abruptly.
>>>
>>>
>>> Alternatively, I don't mind to change this to 'bm' or something like
>>> that for Mogan, but some operators told me that it will confuse users more
>>> to have both 'baremetal' and 'bm' in there CLI.
>>> And as I understand, ironic commands are not used frequently, and it's
>>> even less if ironic inspector can help to automatically enroll nodes/ports.
>>>
>>
>> I don't share this understanding, depends on a situation. A user of a
>> purely baremetal cloud, or an installer like TripleO, may use the baremetal
>> commands all the time.
>>
>>
>>>
>>> The commands we have implemented are listed below, seems there's
>>> no
>>> collision with Ironic presently, and Ironic doesn't manage such
>>> resources.
>>>
>>> * openstack baremetal server  
>>> * openstack bareemtal flavor  
>>> * openstack baremetal keypair  
>>> * openstack baremetal availability zone  
>>>
>>>
>>> Ironic does not have any notion of either of these, so it should be
>>> fine.
>>>
>>
> When using the openstack CLI I'm often in a 'discovery' mode, particularly
> if I'm interacting with a service that I don't often interact with. I often
> use the tab autocomplete and fuzzy match features of OSC as I explore.
> Having command prefix match multiple services could be confusing,
> particularly if I have python-moganclient installed but no mogan service
> exists.
>
> If there were an additional command prefix for mogan as is used for ironic
> inspector (openstack baremetal introspection ...), this would at least
> group the mogan commands.
>
> * openstack baremetal foo server  
> * openstack baremetal foo flavor  
> * openstack baremetal foo keypair  
> * openstack baremetal foo availability zone  
>
>
In fact, at first we used an additional prefix for mogan (openstack
baremetal compute) like ironic inspector to group our commands, but then we
find there's no collision with the existing commands if we remove the
prefix and
only using 'baremetal'makes users type less. But seems we make this change
from the point of view of an OpenStack developer instead of the OSC users.

We can change to use 'openstack baremetal compute' if it makes less
confusing, It looks like a good alternative to me :)


>
>>> I'm still a bit on a -1 side because of potential users confusion. I
>>> wonder
>>> how can we send a message across that prefixes do not designate a
>>> specific
>>> project, but are rather just part of a "sentence". I'm specifically
>>> worried
>>> about confusing "baremetal server" of Mogan with "baremetal node" of
>>> Ironic.
>>> For many people these can be synonyms.
>>>
>>>
>>> We copied nova's server resource concept here, so users may easily to
>>> accept the 'baremetal server'. For 'baremetal node', seems only
>>> operators/administrators may use such commands, so seems the synonyms is
>>> not a big problem as they are for different roles.
>>>
&g

Re: [openstack-dev] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

On Thu, May 25, 2017 at 4:27 PM, Dmitry Tantsur <dtant...@redhat.com> wrote:

> On 05/25/2017 10:20 AM, Zhenguo Niu wrote:
>
>> hi all,
>>
>
> Hi!
>
>
>> I'm from the Mogan team, we chose the same keyward 'baremetal' when
>> implementing a OSC plugin [1]. As we think the baremetal command is
>> representative of a baremetal resource, not a service, so it makes sense
>> for different projects to share the top level resource name that OpenStack
>> can provide.
>>
>
> We do not "own" the word "baremetal", so nothing prevents you from using
> it. However, in my experience:
> 1. This does confuse users, as they expect "openstack baremetal" to be a
> prefix belonging to Ironic.
> 2. Collisions may happen. We had two collisions with TripleO already, one
> resulted in us killing a TripleO command abruptly.
>
>
Alternatively, I don't mind to change this to 'bm' or something like that
for Mogan, but some operators told me that it will confuse users more to
have both 'baremetal' and 'bm' in there CLI.
And as I understand, ironic commands are not used frequently, and it's even
less if ironic inspector can help to automatically enroll nodes/ports.



>
>> The commands we have implemented are listed below, seems there's no
>> collision with Ironic presently, and Ironic doesn't manage such resources.
>>
>> * openstack baremetal server  
>> * openstack bareemtal flavor  
>> * openstack baremetal keypair  
>> * openstack baremetal availability zone  
>>
>
> Ironic does not have any notion of either of these, so it should be fine.
>
> I'm still a bit on a -1 side because of potential users confusion. I
> wonder how can we send a message across that prefixes do not designate a
> specific project, but are rather just part of a "sentence". I'm
> specifically worried about confusing "baremetal server" of Mogan with
> "baremetal node" of Ironic. For many people these can be synonyms.
>
>
We copied nova's server resource concept here, so users may easily to
accept the 'baremetal server'. For 'baremetal node', seems only
operators/administrators may use such commands, so seems the synonyms is
not a big problem as they are for different roles.


>
>> So, we'd like to ask if our CLI pattern is allowed before we release the
>> client.
>>
>> Thanks in advance!
>>
>>
>> [1] https://github.com/openstack/python-moganclient
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>>
>> 
>> __
>> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [OSC][ironic][mogan] Can we share the same keyword 'baremetal'?

[Zhenguo Niu]

hi all,

I'm from the Mogan team, we chose the same keyward 'baremetal' when
implementing a OSC plugin [1]. As we think the baremetal command is
representative of a baremetal resource, not a service, so it makes sense
for different projects to share the top level resource name that OpenStack
can provide.

The commands we have implemented are listed below, seems there's no
collision with Ironic presently, and Ironic doesn't manage such resources.

* openstack baremetal server  
* openstack bareemtal flavor  
* openstack baremetal keypair  
* openstack baremetal availability zone  

So, we'd like to ask if our CLI pattern is allowed before we release the
client.

Thanks in advance!


[1] https://github.com/openstack/python-moganclient

-- 
Best Regards,
Zhenguo Niu
__
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] [mogan][valence] Valence integration

[Zhenguo Niu]

OK, thanks Yang, Lin, I will prepare a spec for the new flavor soon!

On Tue, Mar 28, 2017 at 1:32 AM, Yang, Lin A <lin.a.y...@intel.com> wrote:

> Hi Zhenguo,
>
>
>
> The spec looks prefect to me, thanks a lot for doing that.
>
>
>
> The python-valenceclient is high priority of valence Pike release, and
> still undergoing right now. We plan to release the python binding library
> at first. Now you need a simple wrapper if you start coding right now.
>
>
>
> Regards,
>
> Lin.
>
>
>
> *From:* Zhenguo Niu [mailto:niu.zgli...@gmail.com]
> *Sent:* Friday, March 24, 2017 7:23 PM
> *To:* Yang, Lin A <lin.a.y...@intel.com>
> *Cc:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* Re: [openstack-dev] [mogan][valence] Valence integration
>
>
>
> Thanks Yang, Lin for the explanation!
>
>
>
> The Valence flavor shows a good example for baremetal instances, we do
> need such a flavor :D
>
>
>
> I will draft a spec for this, you can help to review later. Another
> question is whether the Valence client is ready to use or we need to wrap
> the REST API ourselves?
>
>
>
>
>
>
>
> On Sat, Mar 25, 2017 at 9:37 AM, Yang, Lin A <lin.a.y...@intel.com> wrote:
>
> Hi Zhenguo,
>
>
>
> Please checkout the latest valence api spec, current it support two ways
> to specify the arguments when composing node via valence api.
>
> 1. Specify flavor for composition -  Specify flavor uuid in ‘flavor_id’
> field {flavor_id: flavor_uuid} besides the name and description fields. An
> example of request body shows as below.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘flavor_id’: ‘fake_uuid’}
>
>
>
> 2. Specify every hardware details, like cpu, memory, local/remote drive,
> nic, in ‘properties’ field.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘properties’: {‘processor’: {‘total_cores’:8,
>
> ‘model’:
> ‘fale_model’},
>
> ‘memore’: {‘capacity_mib’: 4096,
>
>   ‘type’: ‘DDR3’}}}
>
> We will update user document to list all available parameters for node
> composition soon.
>
>
>
> [0] https://github.com/openstack/valence/blob/
> 0db8a8e186e25ded2b17460f5ae2ce9abf576851/api-ref/source/
> valence-api-v1-nodes.inc
>
>
>
> Thanks,
>
> Lin.
>
> *From:* Zhenguo Niu [mailto:niu.zgli...@gmail.com]
> *Sent:* Tuesday, March 21, 2017 4:20 AM
> *To:* OpenStack Development Mailing List <openstack-dev@lists.
> openstack.org>
> *Subject:* [openstack-dev] [mogan][valence] Valence integration
>
>
>
> hi guys,
>
>
>
> Here is a spec about Mogan and Valence integration[1], but before this
> happen, I would like to know what information needed when requesting to
> compose a node through Valence. From the API doc[2], I can only find name
> and description parameters, but seems like it's incorrect, I suppose that
> it should at least include cpus, ram, disk or maybe cpuinfo. We need to
> align with this before introducing a new flavor for both RSD nodes and
> generic nodes.
>
>
>
>
>
> [1] https://review.openstack.org/#/c/441790/
>
> [2] https://github.com/openstack/valence/blob/master/
> api-ref/source/valence-api-v1-nodes.inc#request
>
>
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>
>
>
>
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>



-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Nominating liusheng for Mogan core

[Zhenguo Niu]

Welcome liusheng to Mogan core!

On Fri, Mar 24, 2017 at 8:23 PM, Feng, Shaohe <shaohe.f...@intel.com> wrote:

> Liusheng deserved it for his great contribution.
>
> ＋１
> Thanks.
>
> BR
> Ｓｈａｏｈｅ
>
>
> On Mon, Mar 20, 2017 at 4:19 PM, Zhenguo Niu <niu.zgli...@gmail.com>
> wrote:
>
>> Hi team,
>>
>> I would like to nominate liusheng to Mogan core. Liusheng has been a
>> significant code contributor since the project's creation providing high
>> quality reviews.
>>
>> Please feel free to respond in public or private your support or any
>> concerns.
>>
>>
>> Thanks,
>> Zhenguo
>>
>> 
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [mogan][valence] Valence integration

[Zhenguo Niu]

Thanks Yang, Lin for the explanation!

The Valence flavor shows a good example for baremetal instances, we do need
such a flavor :D

I will draft a spec for this, you can help to review later. Another
question is whether the Valence client is ready to use or we need to wrap
the REST API ourselves?



On Sat, Mar 25, 2017 at 9:37 AM, Yang, Lin A <lin.a.y...@intel.com> wrote:

> Hi Zhenguo,
>
>
>
> Please checkout the latest valence api spec, current it support two ways
> to specify the arguments when composing node via valence api.
>
> 1. Specify flavor for composition -  Specify flavor uuid in ‘flavor_id’
> field {flavor_id: flavor_uuid} besides the name and description fields. An
> example of request body shows as below.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘flavor_id’: ‘fake_uuid’}
>
>
>
> 2. Specify every hardware details, like cpu, memory, local/remote drive,
> nic, in ‘properties’ field.
>
>   {‘name’: ‘new_node’,
>
>‘description’: ‘test composition’,
>
>‘properties’: {‘processor’: {‘total_cores’:8,
>
> ‘model’:
> ‘fale_model’},
>
> ‘memore’: {‘capacity_mib’: 4096,
>
>   ‘type’: ‘DDR3’}}}
>
> We will update user document to list all available parameters for node
> composition soon.
>
>
>
> [0] https://github.com/openstack/valence/blob/
> 0db8a8e186e25ded2b17460f5ae2ce9abf576851/api-ref/source/
> valence-api-v1-nodes.inc
>
>
>
> Thanks,
>
> Lin.
>
> *From:* Zhenguo Niu [mailto:niu.zgli...@gmail.com]
> *Sent:* Tuesday, March 21, 2017 4:20 AM
> *To:* OpenStack Development Mailing List <openstack-dev@lists.
> openstack.org>
> *Subject:* [openstack-dev] [mogan][valence] Valence integration
>
>
>
> hi guys,
>
>
>
> Here is a spec about Mogan and Valence integration[1], but before this
> happen, I would like to know what information needed when requesting to
> compose a node through Valence. From the API doc[2], I can only find name
> and description parameters, but seems like it's incorrect, I suppose that
> it should at least include cpus, ram, disk or maybe cpuinfo. We need to
> align with this before introducing a new flavor for both RSD nodes and
> generic nodes.
>
>
>
>
>
> [1] https://review.openstack.org/#/c/441790/
>
> [2] https://github.com/openstack/valence/blob/master/
> api-ref/source/valence-api-v1-nodes.inc#request
>
>
>
> --
>
> Best Regards,
>
> Zhenguo Niu
>



-- 
Best Regards,
Zhenguo Niu
__
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] [mogan][valence] Valence integration

[Zhenguo Niu]

hi guys,

Here is a spec about Mogan and Valence integration[1], but before this
happen, I would like to know what information needed when requesting to
compose a node through Valence. From the API doc[2], I can only find name
and description parameters, but seems like it's incorrect, I suppose that
it should at least include cpus, ram, disk or maybe cpuinfo. We need to
align with this before introducing a new flavor for both RSD nodes and
generic nodes.


[1] https://review.openstack.org/#/c/441790/
[2]
https://github.com/openstack/valence/blob/master/api-ref/source/valence-api-v1-nodes.inc#request

-- 
Best Regards,
Zhenguo Niu
__
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] [mogan] Nominating liusheng for Mogan core

[Zhenguo Niu]

Hi team,

I would like to nominate liusheng to Mogan core. Liusheng has been a
significant code contributor since the project's creation providing high
quality reviews.

Please feel free to respond in public or private your support or any
concerns.


Thanks,
Zhenguo
__
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] [karbor][stackalytics] Karbor Missing Commits in Stackalytics

[Zhenguo Niu]

hi Ilya,

I set up a local stackalytics and it works well, all git-related stats
prior to the renaming of Mogan are displayed.

On Thu, Feb 9, 2017 at 9:37 PM, Ilya Shakhat <ishak...@mirantis.com> wrote:

> Sure, I'll take a look at this.
>
> --Ilya
>
> 2017-02-09 13:47 GMT+04:00 Zhenguo Niu <niu.zgli...@gmail.com>:
>
>> After the rename of Nimble to Mogan, all git-related stats are lost as
>> well.
>>
>> http://stackalytics.com/?metric=commits_type=opensta
>> ck-others=mogan
>>
>> Ilya, Can you please assist with rectifying this?
>>
>> On Thu, Feb 9, 2017 at 5:00 PM, Thierry Carrez <thie...@openstack.org>
>> wrote:
>>
>>> Yuval Brik wrote:
>>> > By looking
>>> > at http://stackalytics.com/?metric=commits=all_
>>> type=all=karbor
>>> > <http://stackalytics.com/?metric=commits=all
>>> _type=all=karbor> I
>>> > noticed that Karbor has only 195 commits in Stackalytics, while in
>>> fact,
>>> > it has 721 commits (438 of them are not Jenkin's merges). It seems like
>>> > this happens because of the past Smaug -> Karbor rename. The cause
>>> might
>>> > be the fact that Stackalytics only counts diffs, and older commits are
>>> > already counted for Smaug instead of Karbor, but I'm not sure, and have
>>> > no way of verifying that.
>>> > The problem happens only in the Stackalytics commits and lines of code
>>> > sections, and affects karbor-dashboard and python-karborclient as well.
>>> > The reviews part in Stackalytics seem to be accurate
>>> > ( http://stackalytics.com/?metric=marks=all_ty
>>> pe=all=karbor
>>> > <http://stackalytics.com/?metric=marks=all_t
>>> ype=all=karbor> )
>>> >
>>> > Can anyone advise?
>>>
>>> I suspect you're right, must be related to the rename. I would have
>>> thought adding aliases would be sufficient:
>>>
>>> http://git.openstack.org/cgit/openstack/stackalytics/commit/
>>> ?id=606df2029ab4d3d03ba43fe6d3884346cb59ef16
>>>
>>> Maybe Ilya can shed some light onto this...
>>>
>>> --
>>> Thierry Carrez (ttx)
>>>
>>> 
>>> __
>>> 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
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Zhenguo Niu
>>
>> ________
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [karbor][stackalytics] Karbor Missing Commits in Stackalytics

[Zhenguo Niu]

After the rename of Nimble to Mogan, all git-related stats are lost as well.

http://stackalytics.com/?metric=commits_type=
openstack-others=mogan

Ilya, Can you please assist with rectifying this?

On Thu, Feb 9, 2017 at 5:00 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Yuval Brik wrote:
> > By looking
> > at http://stackalytics.com/?metric=commits=all;
> project_type=all=karbor
> > <http://stackalytics.com/?metric=commits=all;
> project_type=all=karbor> I
> > noticed that Karbor has only 195 commits in Stackalytics, while in fact,
> > it has 721 commits (438 of them are not Jenkin's merges). It seems like
> > this happens because of the past Smaug -> Karbor rename. The cause might
> > be the fact that Stackalytics only counts diffs, and older commits are
> > already counted for Smaug instead of Karbor, but I'm not sure, and have
> > no way of verifying that.
> > The problem happens only in the Stackalytics commits and lines of code
> > sections, and affects karbor-dashboard and python-karborclient as well.
> > The reviews part in Stackalytics seem to be accurate
> > ( http://stackalytics.com/?metric=marks=all;
> project_type=all=karbor
> > <http://stackalytics.com/?metric=marks=all;
> project_type=all=karbor> )
> >
> > Can anyone advise?
>
> I suspect you're right, must be related to the rename. I would have
> thought adding aliases would be sufficient:
>
> http://git.openstack.org/cgit/openstack/stackalytics/commit/?id=
> 606df2029ab4d3d03ba43fe6d3884346cb59ef16
>
> Maybe Ilya can shed some light onto this...
>
> --
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [nimble] Project name collision

[Zhenguo Niu]

hi all,

Thanks for joining the IRC team meeting!

According to the result of the vote, we need to change the project name
from Nimble to Mogan[1], and the renaming process can be found here[2].

[1] https://en.wikipedia.org/wiki/Mount_Mogan
[2] https://etherpad.openstack.org/p/nimble-renaming

On Mon, Dec 26, 2016 at 1:06 PM, Zhenguo Niu <niu.zgli...@gmail.com> wrote:

> hi all,
>
> Unfortunately, 'Nimble' is used by a company, We should rename the project
> to avoid name collision.
>
> There are already some names proposed, we will vote to choose a new name
> in the next IRC team meeting this week, Dec 29.
>
> Looking forward for new name proposals :)
>
> Thanks!
>
> --
> Best Regards,
> Zhenguo Niu
>



-- 
Best Regards,
Zhenguo Niu
__
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] [nimble] Project name collision

[Zhenguo Niu]

hi all,

Unfortunately, 'Nimble' is used by a company, We should rename the project
to avoid name collision.

There are already some names proposed, we will vote to choose a new name in
the next IRC team meeting this week, Dec 29.

Looking forward for new name proposals :)

Thanks!

-- 
Best Regards,
Zhenguo Niu
__
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] [nimble] Weekly meeting canceled this week (1/12/2016)

[Zhenguo Niu]

Hello team,

I'll cancel tomorrow's IRC meeting due to Bug Smash activities.

See you all on next meeting!

-- 
Best Regards,
Zhenguo Niu
__
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] [new][nimble] New project: Nimble

[Zhenguo Niu]

On Mon, Nov 28, 2016 at 1:37 PM, Jay Pipes <jaypi...@gmail.com> wrote:
>
>
> For the RackScale Architecture stuff, the Valence project seems to be
> doing that and I'm not sure what role Nimble would play.
>

For Valence, as my understanding, it provides interfaces to help
compose/release nodes. Nimble will talk to Valence to compose nodes for
users' requests, then enroll the composed node to Ironic to provision it
like generic nodes. Another way is to add Valence to Nova as a driver or
integrate into ironic dirver, but I think it's not easiliy possible. Please
correct me if I misunderstand Valance, thanks!

-- 
Best Regards,
Zhenguo Niu
__
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] [new][nimble] New project: Nimble

[Zhenguo Niu]

Thanks Sean McGinnis for pointing it out!

On Sat, Nov 26, 2016 at 12:40 AM, Sean McGinnis <sean.mcgin...@gmx.com>
wrote:

> On Fri, Nov 25, 2016 at 05:41:28PM +0800, Zhenguo Niu wrote:
> > hi all,
> >
> > We are pleased to introduce Nimble, a new OpenStack project which aims to
> > provide bare metal computing management.
>
> Has this name been cleared for use? Nimble is the name of a company, so
> like Quantum, this seems to me to be a short lived name.
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [new][nimble] New project: Nimble

[Zhenguo Niu]

hi Jay,

Ironic's existing API is admin only, which should not be exposed to end
users, it is best thought of as a bare metal hypervisor API.
And Ironic lacks the ability of scheduling, quotas management and
multi-tenancy support, it heavily depends on Nova to expose API to
end users.

Nova focuses on VM management and provides virtualization specific
features, although the ironic driver makes it possible to manage
bare metal via Nova's API, it doesn't work well. It's hard to add bare
metal specific features, as Nova API is for all hypervisors,
especially virtualization hypervisors. And in order to work with Nova, we
have to adapt the way to manage VMs, for example, we only
have one compute host for all bare metal nodes, so all capabilities based
on compute hosts can't apply to bare metals like availability
zones, host aggregates, etc.

Like containers and virutalizations, bare metal is also a different
technology, different resource. I think they don't work better
together within a same nova compute and bounded by Nova unified API. So we
decide to create a new project which decouples the two
technologies by separating baremetal management into it's own set of API.

Another reason is we also want to support RSD bared servers. Then composing
resouces work will be done in Nimble, Ironic only need
to add RedFish driver to support this type of servers.

Thanks,


On Mon, Nov 28, 2016 at 8:16 AM, Jay Pipes <jaypi...@gmail.com> wrote:

> On 11/25/2016 04:41 AM, Zhenguo Niu wrote:
>
>> hi all,
>>
>> We are pleased to introduce Nimble, a new OpenStack project which aims
>> to provide bare metal computing management.
>> Compared with Nova, it's more bare metal specific and with more advanced
>> features that VM users don't need, it's not
>> bounded by Nova's API.
>>
>> As we know, Ironic API should never be exposed to end users, users have
>> to talk to Nova to request a bare metal compute
>> instance even if you're only providing bare metal, even if it's only
>> internally, you still have to talk to nova, Ironic doesn't have
>> a concept of users, tenants, and quotas. Nimble wants to decouple
>> virtualization and baremetal technologies by breaking
>> baremetal computing management into its own set of application program
>> interfaces.
>>
>> Not only does Nimble provide pre-set configuration servers, but it also
>> wants to support RSD(Rack Scale Design) which makes
>> it possible to dynamically compose physical resouces.
>>
>> For more information, including architecture, use cases, etc., are
>> described on the project wiki [0].
>> And please feel free to browse our source code [1][2].
>>
>
> I'm a little confused why you are choosing to create a new RESTful API
> service instead of working to adapt Ironic's existing API, or alternately,
> working with the Nova team to add features that you feel were/are necessary
> for baremetal management.
>
> What were the primary reasons you decided not to work with either (or
> both) of the Ironic or Nova communities?
>
> -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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [new][nimble] New project: Nimble

[Zhenguo Niu]

hi all,

We are pleased to introduce Nimble, a new OpenStack project which aims to
provide bare metal computing management.
Compared with Nova, it's more bare metal specific and with more advanced
features that VM users don't need, it's not
bounded by Nova's API.

As we know, Ironic API should never be exposed to end users, users have to
talk to Nova to request a bare metal compute
instance even if you're only providing bare metal, even if it's only
internally, you still have to talk to nova, Ironic doesn't have
a concept of users, tenants, and quotas. Nimble wants to decouple
virtualization and baremetal technologies by breaking
baremetal computing management into its own set of application program
interfaces.

Not only does Nimble provide pre-set configuration servers, but it also
wants to support RSD(Rack Scale Design) which makes
it possible to dynamically compose physical resouces.

For more information, including architecture, use cases, etc., are
described on the project wiki [0].
And please feel free to browse our source code [1][2].

If you're intreasted in Nimble, please join!

Thanks,

[0] https://wiki.openstack.org/wiki/Nimble
[1] https://github.com/openstack/nimble
[2] https://github.com/openstack/python-nimbleclient
__
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] [ironic] ironic-inspector-core team update

[Zhenguo Niu]

+1, well deserved!

On Mon, Sep 26, 2016 at 8:55 PM, milanisko k <vetri...@gmail.com> wrote:

> Thanks guys! :D
>
> --
> milan
>
> po 26. 9. 2016 v 14:46 odesílatel Jim Rollenhagen <j...@jimrollenhagen.com>
> napsal:
>
>> // jim
>>
>>
>> On Mon, Sep 26, 2016 at 5:24 AM, Dmitry Tantsur <dtant...@redhat.com>
>> wrote:
>> > Hi folks!
>> >
>> > As you probably know, Imre has decided to leave us for other
>> challenges, so
>> > our small core team has become even smaller. I'm removing him on his
>> > request.
>> >
>> > I suggest adding Milan Kovacik (milan or mkovacik on IRC) to the
>> > ironic-inspector-core team. He's been pretty active on ironic-inspector
>> > recently, doing meaningful reviews, and he's driving our HA work
>> forward.
>> >
>> > Please vote with +1/-1. If no objections are recorded, the change will
>> be in
>> > effect next Monday.
>> >
>> > Thanks!
>>
>> +1, Milan seems to be killing it. :)
>>
>> // jim
>>
>> 
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [ironic][nova][horizon] Serial console support for ironic instances

[Zhenguo Niu]

Thanks Yuiko for doing this, but I'm sorry that I can't go to Austin, so I
would like to add more details about my proposal here, hope someone can
bring it to the session.

Add a custom HTTP proxy for web based consoles to Nova
https://review.openstack.org/#/c/300582/

* Pros:
- for Ironic
  - Don't need any change to Ironic API
  - We can continue use the web interface from Ironic, don't rely on
Nova's websocketproxy to provide a ws/wss URL
- for Nova and Horizon
  - Support one more console type for hypervisors which provide web
based consoles not only for Ironic, here's another one which also needs it
https://blueprints.launchpad.net/nova/+spec/spice-http-proxy

* Cons:
- Don't output log file
  but I think session logging capability is a great extension for
shellinabox, will explore this more.


And Ironic will support different console drivers, I don't think only one
proposal will be accepted here.

On Thu, Apr 14, 2016 at 10:11 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Wed, Apr 13, 2016 at 05:47:15PM +0900, Yuiko Takada wrote:
> > Hi,
> >
> > I also want to discuss about it at summit session.
> >
> > 2016-04-13 0:41 GMT+09:00 Ruby Loo <rlooya...@gmail.com>:
> >
> > > Yes, I think it would be good to have a summit session on that.
> However,
> > > before the session, it would really be helpful if the folks with
> proposals
> > > got together and/or reviewed each other's proposals, and summarized
> their
> > > findings.
> > >
> >
> > I've summarized all of related proposals.
> >
> > (1)Add driver using Socat
> > https://review.openstack.org/#/c/293827/
> >
> > * Pros:
> > - There is no influence to other components
> > - Don't need to change any other Ironic drivers(like
> IPMIShellinaboxConsole)
> > - Don't need to bump API microversion/RPC
> >
> > * Cons:
> > - Don't output log file
> >
> > (2)Add driver starting ironic-console-server
> > https://review.openstack.org/#/c/302291/
> > (There is no spec, yet)
> >
> > * Pros:
> > - There is no influence to other components
> > - Output log file
> > - Don't need to change any other Ironic drivers(like
> IPMIShellinaboxConsole)
> > - No adding any Ironic services required, only add tools
> >
> > * Cons:
> > - Need to bump API microversion/RPC
> >
> > (3)Add a custom HTTP proxy to Nova
> > https://review.openstack.org/#/c/300582/
> >
> > * Pros:
> > - Don't need any change to Ironic API
> >
> > * Cons:
> > - Need Nova API changes(bump microversion)
> > - Need Horizon changes
> > - Don't output log file
> >
> > (4)Add Ironic-ipmiproxy server
> > https://review.openstack.org/#/c/296869/
> >
> > * Pros:
> > - There is no influence to other components
> > - Output log file
> > - IPMIShellinaboxConsole will be also available via Horizon
> >
> > * Cons:
> > - Need IPMIShellinaboxConsole changes?
> > - Need to bump API microversion/RPC
> >
> > If there is any mistake, please give me comment.
>
> Thanks for doing this Yuiko, this will be helpful for everyone preparing
> for this session. Looking forward to chatting about it. :)
>
> // jim
>
> >
> >
> > Best Regards,
> > Yuiko Takada
> >
> > 2016-04-13 0:41 GMT+09:00 Ruby Loo <rlooya...@gmail.com>:
> >
> > > Yes, I think it would be good to have a summit session on that.
> However,
> > > before the session, it would really be helpful if the folks with
> proposals
> > > got together and/or reviewed each other's proposals, and summarized
> their
> > > findings. You may find after reviewing the proposals, that eg only 2
> are
> > > really different. Or they several have merit because they are
> addressing
> > > slightly different issues. That would make it easier to
> > > present/discuss/decide at the session.
> > >
> > > --ruby
> > >
> > >
> > > On 12 April 2016 at 09:17, Jim Rollenhagen <j...@jimrollenhagen.com>
> wrote:
> > >
> > >> On Tue, Apr 12, 2016 at 02:02:44AM +0800, Zhenguo Niu wrote:
> > >> > Maybe we can continue the discussion here, as there's no enough
> time in
> > >> the
> > >> > irc meeting :)
> > >>
> > >> Someone mentioned this would make a good summit session, as there's a
> > >> few competing proposals that are all good options. I do welcome
> > >> discussion here until then, but I'm going to put it on the schedule.
> :)
> > 

Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell for Horizon stable core

[Zhenguo Niu]

definitely +1

On Fri, Apr 8, 2016 at 12:42 AM, Brad Pokorny <brad_poko...@symantec.com>
wrote:

> +1. I think Rob will provide good input for stable.
>
> Thanks,
> Brad
>
> From: Timur Sufiev <tsuf...@mirantis.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Thursday, April 7, 2016 at 4:31 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Horizon][stable] proposing Rob Cresswell
> for Horizon stable core
>
> +1
> Чт, 7 апр. 2016 г. в 14:04, Itxaka Serrano Garcia <itx...@redhat.com>:
>
>> Im still not sure if non-cores (i.e. peasants like me) can vote but I
>> will do it anyway :D
>>
>> A big +1 from me.
>>
>> Itxaka
>>
>> On 04/07/2016 12:01 PM, Matthias Runge wrote:
>> > Hello,
>> >
>> > I'm proposing Rob Cresswell to become stable core for Horizon. I
>> > thought, in the past all PTL were in stable team, but this doesn't seem
>> > to be true any more.
>> >
>> > Please chime in with +1/-1
>> >
>>
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [ironic] Nominating Julia Kreger for core reviewer

[Zhenguo Niu]

+1, thanks for all the hard work Julia!

On Fri, Mar 25, 2016 at 8:39 AM, 守屋哲 / MORIYA，SATORU <
satoru.moriya...@hitachi.com> wrote:

> +1 for me. She has given lots of valuable reviews to boot from volume
> effort.
> Thanks Julia!
>
> Satoru
>
> > -Original Message-
> > From: Jim Rollenhagen [mailto:j...@jimrollenhagen.com]
> > Sent: Friday, March 25, 2016 4:09 AM
> > To: openstack-dev@lists.openstack.org
> > Subject: [!][openstack-dev] [ironic] Nominating Julia Kreger for core
> reviewer
> >
> > Hey all,
> >
> > I'm nominating Julia Kreger (TheJulia in IRC) for ironic-core. She runs
> > the Bifrost project, gives super valuable reviews, is beginning to lead
> > the boot from volume efforts, and is clearly an expert in this space.
> >
> > All in favor say +1 :)
> >
> > // jim
> >
> >
> __
> > 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [horizon] PTL noncandidacy

[Zhenguo Niu]

David,

Thanks for your commitment and leadership, really appreciated all the help
from you!

On Tue, Mar 15, 2016 at 5:41 AM, Diana Whitten <hurgleburg...@gmail.com>
wrote:

> David,
>
> I don't envy the person who has to fill these shoes.  You've been amazing!
>
> - Diana
>
> On Mon, Mar 14, 2016 at 1:04 PM, Timur Sufiev <tsuf...@mirantis.com>
> wrote:
>
>> David,
>>
>> It's sad news for us, and a well-deserved vacation from bureaucratic
>> hassles for you! Will try hard to not break Horizon in your absence.
>>
>> On Mon, 14 Mar 2016 at 22:46, Doug Fish <the.doug.f...@gmail.com> wrote:
>>
>>> David, congratulations on a job well done!
>>>
>>> Doug
>>>
>>> On Mar 14, 2016, at 8:39 AM, Liz Blanchard <lsure...@redhat.com> wrote:
>>>
>>>
>>>
>>> On Fri, Mar 11, 2016 at 12:19 PM, David Lyle <dkly...@gmail.com> wrote:
>>>
>>>> After five cycles as PTL of Horizon, I've decided not to run for the
>>>> Newton cycle.
>>>>
>>>
>>> David,
>>>
>>> Thank you for everything you've done for Horizon, especially around
>>> helping push a focus on User Experience.
>>>
>>> Best,
>>> Liz
>>>
>>>
>>>>
>>>> I am exceptionally proud of the things we've accomplished over this
>>>> time. I'm amazed by how much our project's community has grown and
>>>> evolved.
>>>>
>>>> Looking at the community now, I believe we have a tremendous group of
>>>> contributors for moving forward. There are several people capable of
>>>> becoming great PTLs and overall the community will be healthier with
>>>> some turnover in the PTL role. I feel honored to have had your trust
>>>> over this time and lucky to have worked with such great people.
>>>>
>>>> I will still be around and will help the next PTL make a smooth
>>>> transition where requested.
>>>>
>>>> David
>>>>
>>>>
>>>> __
>>>> 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
>>
>>
>
> __
> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [horizon] Proposal to add Diana Whitten tohorizon-core

[Zhenguo Niu]

+1 from me, thanks for all the hard work!

On Thu, Mar 10, 2016 at 3:27 AM, Michael Krotscheck <krotsch...@gmail.com>
wrote:

> +1. Another vote in favor of ditching django altogether is good by me :)
>
> On Wed, Mar 9, 2016 at 11:25 AM Thai Q Tran <tqt...@us.ibm.com> wrote:
>
>> Big +1 from me, thanks for all the hard work Diana!
>>
>>
>> - Original message -
>> From: David Lyle <dkly...@gmail.com>
>> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org
>> >
>> Cc:
>> Subject: [openstack-dev] [horizon] Proposal to add Diana Whitten to
>> horizon-core
>> Date: Tue, Mar 8, 2016 2:07 PM
>>
>> I propose adding Diana Whitten[1] to horizon-core.
>>
>> Diana is an active reviewer, contributor and community member. Over
>> the past couple of releases, Diana has driven extensive changes around
>> theme-ability in Horizon and drastically increased the standardization
>> of our use of bootstrap. During this time, Diana has also provided
>> valuable reviews to keep us on the straight and narrow preventing our
>> continued abuse of defenseless web technologies.
>>
>> Please respond with comments, +1s, or objections by Friday.
>>
>> Thanks,
>> David
>>
>> [1]
>> http://stackalytics.com/?module=horizon-group_id=hurgleburgler=all
>>
>> __
>> 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
>
>


-- 
Best Regards,
Zhenguo Niu
__
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] [horizon] Proposal to add Richard Jones to horizon-core

[Zhenguo Niu]

+1 for both

On Thu, Dec 3, 2015 at 2:57 AM, David Lyle <dkly...@gmail.com> wrote:

> Let's try that again.
>
> I propose adding Richard Jones[1] to horizon-core.
>
> Over the last several cycles Richard has consistently been providing
> great reviews, actively participating in the Horizon community, and
> making meaningful contributions around angularJS and overall project
> stability and health.
>
> Please respond with comments, +1s, or objections within one week.
>
> Thanks,
> David
>
> [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> On Wed, Dec 2, 2015 at 11:56 AM, David Lyle <dkly...@gmail.com> wrote:
> > I propose adding Richard Jones[1] to horizon-core.
> >
> > Over the last several cycles Timur has consistently been providing
> > great reviews, actively participating in the Horizon community, and
> > making meaningful contributions around angularJS and overall project
> > stability and health.
> >
> > Please respond with comments, +1s, or objections within one week.
> >
> > Thanks,
> > David
> >
> > [1]
> http://stackalytics.com/?module=horizon-group_id=r1chardj0n3s=all
>
> __
> 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
>



-- 
Best Regards,
Zhenguo Niu
__
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] [Horizon] Bug day! Yeah!

[Zhenguo Niu]

Thanks Rob, next Tuesday is fine with me.

-Zhenguo

Sent from my iPhone

> On Nov 19, 2015, at 19:19, Rob Cresswell (rcresswe)  
> wrote:
> 
> Hey folks,
> 
> Our bug list is… rather large. We’ve discussed having a bug day, where as a 
> community we all dedicate some time to triaging bugs and discussing in the 
> IRC channel as we go.
> 
> First off, see the docs about bug triage: 
> https://wiki.openstack.org/wiki/BugTriage
> 
> Secondly, lets pick a date. I’d suggest next Tuesday (24th November); if that 
> doesn’t work for a good number of us, then the following Tuesday (1st 
> December). Trying to account for Thanksgiving :)
> 
> Rob
> __
> 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] [Horizon]

[Zhenguo Niu]

+1 for both!

On Wed, Nov 26, 2014 at 7:29 AM, Lin Hua Cheng os.lch...@gmail.com wrote:


 +1 for both!

 Yep, thanks for all the hard work!

 On Tue, Nov 25, 2014 at 1:35 PM, Ana Krivokapic akriv...@redhat.com
 wrote:


 On 25/11/14 00:09, David Lyle wrote:
  I am pleased to nominate Thai Tran and Cindy Lu to horizon-core.
 
  Both Thai and Cindy have been contributing significant numbers of high
  quality reviews during Juno and Kilo cycles. They are consistently
  among the top non-core reviewers. They are also responsible for a
  significant number of patches to Horizon. Both have a strong
  understanding of the Horizon code base and the direction of the project.
 
  Horizon core team members please vote +1 or -1 to the
  nominations either in reply or by private communication. Voting will
  close on Friday unless I hear from everyone before that.
 
  Thanks,
  David
 
 

 +1 for both.

 Cindy and Thai, thanks for your hard work!

 --
 Regards,

 Ana Krivokapic
 Software Engineer
 OpenStack team
 Red Hat Inc.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best Regards,
Zhenguo Niu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominations to Horizon Core

[Zhenguo Niu]

Thank you everyone, I'll do my best!

发自我的 iPhone

 在 Jul 1, 2014，22:37，Lyle, David david.l...@hp.com 写道：
 
 Welcome Zhenguo and Ana to Horizon core.
 
 David
 
 
 On 6/20/14, 3:17 PM, Lyle, David david.l...@hp.com wrote:
 
 I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core.
 
 Zhenguo has been a prolific reviewer for the past two releases providing
 high quality reviews. And providing a significant number of patches over
 the past three releases.
 
 Ana has been a significant reviewer in the Icehouse and Juno release
 cycles. She has also contributed several patches in this timeframe to both
 Horizon and tuskar-ui.
 
 Please feel free to respond in public or private your support or any
 concerns.
 
 Thanks,
 David
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches

[Zhenguo Niu]

I'm afraid we have to revert the PKIZ change since devstack is not support 
django_openstack_auth now and all patches blocked including David's fix.

发自我的 iPhone

 在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com 写道：
 
 Great. This looks like your fix will not require reverting the PKIZ change.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] horizon failing on icehouse 100%, currently blocking all patches

[Zhenguo Niu]

Agreed, we can temporarily pin the version of django_openstack_auth to the 
lower version. 

发自我的 iPhone

 在 Jun 22, 2014，11:09，Morgan Fainberg morgan.fainb...@gmail.com 写道：
 
 I don't think we can revert the change without David's fix. The blocked up 
 gate isn't because of PKIZ in this case (it isn't tested from the horizon 
 part) the blocked up gate is because of the broken django_openstack_auth 
 module. 
 
 Could we just tag a new release based upon the commit of the old release? 
 Then once everything is fixed we tag the real fixed release of 
 django_openstack_auth. It is a little crummy, but would solve it.
 
 Alternatively, we temporarily pin the version of django_openstack_auth to the 
 lower version.
 
 --Morgan 
 
 On Saturday, June 21, 2014, Zhenguo Niu niu.zgli...@gmail.com wrote:
 I'm afraid we have to revert the PKIZ change since devstack is not support 
 django_openstack_auth now and all patches blocked including David's fix.
 
 发自我的 iPhone
 
  在 Jun 22, 2014，5:39，Morgan Fainberg morgan.fainb...@gmail.com 写道：
 
  Great. This looks like your fix will not require reverting the PKIZ change.
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Proposal: Move CPU and memory allocation ratio out of scheduler

[Zhenguo Niu]

+1, makes sense to me.


On Wed, Jun 4, 2014 at 3:08 PM, Yingjun Li liyingjun1...@gmail.com wrote:

 +1, if doing so, a related bug related bug may be solved as well:
 https://bugs.launchpad.net/nova/+bug/1323538

 On Jun 3, 2014, at 21:29, Jay Pipes jaypi...@gmail.com wrote:

 Hi Stackers,

 tl;dr
 =

 Move CPU and RAM allocation ratio definition out of the Nova scheduler and
 into the resource tracker. Remove the calculations for overcommit out of
 the core_filter and ram_filter scheduler pieces.

 Details
 ===

 Currently, in the Nova code base, the thing that controls whether or not
 the scheduler places an instance on a compute host that is already full
 (in terms of memory or vCPU usage) is a pair of configuration options*
 called cpu_allocation_ratio and ram_allocation_ratio.

 These configuration options are defined in, respectively,
 nova/scheduler/filters/core_filter.py and
 nova/scheduler/filters/ram_filter.py.

 Every time an instance is launched, the scheduler loops through a
 collection of host state structures that contain resource consumption
 figures for each compute node. For each compute host, the core_filter and
 ram_filter's host_passes() method is called. In the host_passes() method,
 the host's reported total amount of CPU or RAM is multiplied by this
 configuration option, and the product is then subtracted from the reported
 used amount of CPU or RAM. If the result is greater than or equal to the
 number of vCPUs needed by the instance being launched, True is returned and
 the host continues to be considered during scheduling decisions.

 I propose we move the definition of the allocation ratios out of the
 scheduler entirely, as well as the calculation of the total amount of
 resources each compute node contains. The resource tracker is the most
 appropriate place to define these configuration options, as the resource
 tracker is what is responsible for keeping track of total and used resource
 amounts for all compute nodes.

 Benefits:

 * Allocation ratios determine the amount of resources that a compute node
 advertises. The resource tracker is what determines the amount of resources
 that each compute node has, and how much of a particular type of resource
 have been used on a compute node. It therefore makes sense to put
 calculations and definition of allocation ratios where they naturally
 belong.
 * The scheduler currently needlessly re-calculates total resource amounts
 on every call to the scheduler. This isn't necessary. The total resource
 amounts don't change unless either a configuration option is changed on a
 compute node (or host aggregate), and this calculation can be done more
 efficiently once in the resource tracker.
 * Move more logic out of the scheduler
 * With the move to an extensible resource tracker, we can more easily
 evolve to defining all resource-related options in the same place (instead
 of in different filter files in the scheduler...)

 Thoughts?

 Best,
 -jay

 * Host aggregates may also have a separate allocation ratio that overrides
 any configuration setting that a particular host may have

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best Regards,
Zhenguo Niu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Selenium test fixes

[Zhenguo Niu]

Thank you for the fix.


On Wed, May 28, 2014 at 3:09 PM, Matthias Runge mru...@redhat.com wrote:

 On Wed, May 28, 2014 at 03:45:18PM +1000, Kieran Spear wrote:
  No failures in the last 24 hours. \o/
 

 Thank you for looking into this (and apparently fixing it)!
 --
 Matthias Runge mru...@redhat.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Best Regards,
Zhenguo Niu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Nominating Radomir Dopieralski to Horizon Core

[Zhenguo Niu]

+1

On Friday, March 7, 2014, Akihiro Motoki amot...@gmail.com wrote:

 +1 from me too.
 Having a core member who is familiar with horizon and tuskar-ui code
 base encourages the integration more!

 Akihiro

 On Fri, Mar 7, 2014 at 4:56 PM, Matthias Runge 
 mru...@redhat.comjavascript:;
 wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On Wed, Mar 05, 2014 at 10:36:22PM +, Lyle, David wrote:
  I'd like to nominate Radomir Dopieralski to Horizon Core.  I find his
 reviews very insightful and more importantly have come to rely on their
 quality. He has contributed to several areas in Horizon and he understands
 the code base well.  Radomir is also very active in tuskar-ui both
 contributing and reviewing.
 
  +1 from me, I fully support this. Radomir has done a impressive job
  and his reviews and contributions have been good since he started.
 
  Matthias
  - --
  Matthias Runge mru...@redhat.com javascript:;
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1
 
  iQEcBAEBAgAGBQJTGXu6AAoJEOnz8qQwcaIWoesH/0pP7daAV2xqynR4zmkQ5QnU
  7xcXKWQES/3C0+4YPF4GROvqyRsRtviOnPSkKDDE7W1+6lrZ3/Zc5axqrN5SWkjf
  V1lmNzriHgAOqo9CyXT0JtrrzkILcQ9sFyuGYaHg1iEpa8D6oXC2bwOOWkwGXBXZ
  0lr74B76z46XxR6iHx9WSja02SvySZshIlnf9bJQZtBMDcf1zQq0tPEPLSvkPfeN
  fNLVWj2+PCS4Z6ww8/a4D09fnxf31a2ziG0Anl8aiSj6KuQSlG+FOGv1WfcgLySB
  Pz1MsFvj5J7pF2AYcD2uXGQaWL3DSY6XnFDPcYJ+5KwdjMySJVQiXXG1jTo0wZE=
  =aUPs
  -END PGP SIGNATURE-
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org javascript:;
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org javascript:;
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Best Regards,
Zhenguo Niu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystoneclient] Add a method for changing a user's password in V3

[Zhenguo Niu]

Can someone approve the patch https://review.openstack.org/#/c/59914/ as it
has been open for a long time and without this feature Horizon could not
enable the 'Change Own Password' settings panel when using Keystone v3.

-- 
Best Regards,
Zhenguo Niu
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev